Best practices for requirements development in agile

1. Copyright © 2016 Accenture. All rights reserved. 1
Best Practices for Requirements Development in Agile
Understanding the Business
• Strive to first thoroughly and sufficiently understand the business needs of the client, before jumping to a
solution
• Actively analyze business needs, rules and data to develop requirements, rather than simply collecting
requirements from the client themselves; think broadly about the business objectives
• Focus on the bigger picture (meaning high-level requirements) to provide overall understanding of the
system, rather than pursuing more detailed, up-front requirements, so as to avoid ineffective or unwanted
functionality and excessive documentation
• Realize that requirements are business and solution capabilities that are separate from tasks, technical
design and even business rules, which do not provide context
• Don’t focus too much on the as-is state of the system; instead prioritize understanding the gaps and
determining the future state
• Focus on what and not how; strictly requirements – not design (specific to Edding)
• Allocate sufficient time to understand operational concepts (CONOPS)
• Derive "explicit" and "implicit" lessons learned and requirements from data on the previous project(s)
Working with the Client
• Interact with the client using simple tools (i.e. sticky notes or index cards, rather than “complex” technology)
to prevent stumbling blocks for the stakeholders
• Engage customers to determine relationships between requirements and capabilities together
• Collaborate & review frequently to solidify context and value added
Sprint Zero
• Gather requirements incrementally to accommodate change and shorten the feedback loop
• Prioritize requirements from beginning, as soon as you have 2 or more
• Draft a requirements collection plan and estimate resources needed
• “Identify potential risks that might arise during the requirements collection process (e.g., key stakeholders
are unavailable due to time constraints) and plan risk mitigation strategies.” (MITRE)
• Prioritize and estimate requirements according for each sprint
Crafting the Use Case
• “Create Several Models in Parallel” – perform use cases, user stories, UI prototyping and business rules
simultaneously to complement the strengths and weaknesses of each model and maximize productivity
• “Iterate To Another Artifact”- switch gears amongst artifacts, such as use cases, user stories, UI prototypes
and business rules when you find that you are stuck, to maintain productivity and promote discovery that
will enable you to become “unstuck” with the initial artifact
• “Model In Small Increments” – model smaller portions of a larger model for speed
• Start small, focusing requirements on small, specific capabilities; veer away from making user stories too
large, too complicated, or too vague
• Use visuals to demonstrate relationships, interactions and provide further context

2. 2
Copyright © 2016 Accenture. All rights reserved.
• Provide varying levels of details in requirements to allow the client to consumer the amount of detail of
their choosing when reading the requirements document
• Manage or design requirements to accommodate change
• Revisit requirements often to “further assess trade-offs that users might consider in order to manage
schedule and costs”
• Don’t be afraid to continue to rewriting a user story until it is satisfactory
• Identify requirements that may violate rules, standards and/or regulations
• Use format “As a {user type or component}, I want {action/functionality} so that {resulting business value}”,
determining value first, then user, then action
• Consider use of “who, when, where, what and why” for detail and clarity: As <who> <when> <where>, I
<what> because <why>."
• Avoid using words such as “and” or “but”
• Refer to INVEST guidelines for creating a quality user story
o I – Independent: The user story should be self-contained, in a way that there is no inherent
dependency on another user story.
o N – Negotiable: User stories, up until they are part of an iteration, can always be changed and
rewritten.
o V – Valuable: A user story must deliver value to the end user.
o E – Estimable: You must always be able to estimate the size of a user story.
o S – Small: User stories should not be so big as to become impossible to plan/task/prioritize with a
certain level of certainty.
o T – Testable: The user story or its related description must provide the necessary information to
make test development possible.
• Sample user stories for a workflow:
o As a customer service representative, I need to receive notification from payee of lost payment, so
that I may verify payment information in NATS when administering lost payments.
o As a Retirement Services Specialist, I need to verify service period inaccuracy in applications, so
that I may contact applicants for service period confirmation, when administering refunds.
• Sample user stories for a system interface:
o As the Annuity Roll Processing System (ARPS), I need to receive annuity and survivor data files
from Federal Annuity Claims Expert System (FACES) on a daily basis, so that I may determine
annuity payments.
o As the Annuity Roll Daily Cycle (ARDC), I need to receive court order data from the Annuity Roll
Court Order Recording and Tracking (CORTS) System to update Annuity Roll master files.
• Some requirement attributes are:
o Status
o Creation date and version number
o Requirement author or owner
o Origin or reason for requirement
o Subsystem, iteration, release or build
o Priority
o Risk
o Validation method
• Overall, requirements developed in Agile should meet three criteria: minimal detail, optimal value and
timely delivery

3. 3
Copyright © 2016 Accenture. All rights reserved.
Using JIRA: Do’s and Don’ts
• DO create and use dashboards to stay updated with sprint progress and activities
• DO use Confluence Editor to create requirements and Issues in JIRA
• DO use Confluence to link Epics to Issues in JIRA
• DO assign a Priority, Status and Resolution for each Issue in JIRA
• DO use Issues Links to link Issues to documentation in Confluence and related requirements
• DON’T document requirements outside JIRA – keep all requirements stored in JIRA for easy traceability
• DON’T leave Issues documented without assigned Epics
• DON’T delete previously documented Issues from JIRA
As a Team…
• Work closely as a team, with constant communication and transparency about status
• Be adaptable and don’t be afraid to take on different hats as needed
• Collaborate & review frequently to solidify context and value added
Overall Approach
• Remember to take a software-agnostic approach to developing each requirement
• Remember that agile favors “working software over comprehensive documentation”
• Remember to focus on the what and “not” the “how” (specific to Edding)
Notes
• The issue with developing (software-agnostic) requirements for agile without implementation is that
requirements in agile are usually documented during development based upon what has already been done;
as there will be no implementation on the current project, we will more so be developing user stories
• A user story is essentially a use case – as such, requirement, user story and use case are all used
interchangeably in this document
References
http://agilemodeling.com/essays/agileRequirementsBestPractices.htm#InclusiveModels
http://www.batimes.com/articles/the-top-5-mistakes-in-requirements-practices-and-documentation.html
http://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/requirements-
engineering/eliciting-collecting-and-developing-requirements

4. 4
Copyright © 2016 Accenture. All rights reserved.
Appendix
MITRE Requirements Management Process Flow Diagram