2. Goals
To understand what do we do differently in agile?
To show that requirements still matter in agile
To understand agile requirements practices
To show that context counts, and one “process size” does not fit all
To explore how to scale agile requirements practices
Agile Requirements at Scale 2
3. 3
Agenda
1 Agility and requirements
2 Achieving better requirements on agile
projects: User stories and beyond
3 Brief introduction to Agile requirements at scale
4 Conclusion
Agile Requirements at Scale 3
4. Agile Requirements: Strategies are changing
Continual customer involvement
Product owner represents the stakeholders
Shared vision
Understand business needs
Focus on stakeholders goals
Requirements elicitations
Conversations, agile modeling, workshops
Requirements analysis
Performed “just in time”
Requirements documentation
User stories, storyboards, acceptance tests, agile models
Test your documentation effectiveness : ”CRUFT” Measure
Formality
Improvised, more relaxed approach
Agile Requirements at Scale 4
5. Traditional requirements practices are changing
Specify acceptance tests while you gather requirements
Iterative requirements planning & management
adjusted with planning levels to take into account the progressive
requirements specification
Strategy
Product
Release Portfolio
Iteration
Product
Day
Release
Most agile teams are
concerned only with
Iteration the three innermost
levels of the planning
Source: Scrum onion
Day
Agile Requirements at Scale 5
6. Agile brook down the barriers Prioritized
Requirements Requirement List
Agile planning 101
Requirements Master story Ve
List loc
specs it y
Add user Done
Code Tests
Create profile Done
Tests
Book
Code reservation Done
Make payment
+ MORE
Silos
Agile Team Collaborates
One whole team with Customer
Agile Requirements at Scale 6
7. 7
Agenda
1 Agility and requirements
2 Achieving better requirements on agile
projects: User stories and beyond
3 Brief introduction to Agile requirements at scale
4 Conclusion
Agile Requirements at Scale 7
9. Agile Requirements: User Stories
User story is a concise, written description of a piece of functionality that will be
valuable to a software stakeholder
As a <role>, I can <goal> so that <business value>
Epic User Stories are very large user stories
Break epic stories into iteration-stories
Product Backlog contains ranked list of user stories for a release
User Stories are created at the beginning of the release
Product Owner ranks list based on highest need to stakeholders
But with input from team, e.g. high risk items rank high
Agile Requirements at Scale 9
10. User stories: Ron Jeffrey’s 3 Cs
Card As a (user role), I want to (goal) so I can (reason)
What is the goal of a Example:
user As a registered student, I want to view course details so I can create
my schedule
Conversation Discuss the card with a stakeholder. Just in time analysis (JIT)
How to achieve the through conversations.
goal using the Example:
system? What information is needed to search for a course?
What information is displayed?
Confirmation Record what you learn in an acceptance test.
How to verify if the Example:
story is done and Student can access course catalog 24 x 7 hours
complete, and the
goal is achieved Student cannot choose more than three courses
A user story has 3 parts. If it doesn't, it's not a user story.
Agile Requirements at Scale 10
10
11. Acceptance tests
Acceptance tests are high level tests and captured as
confirmation
They test the completeness of a user story or stories 'played'
during any sprint/iteration.
They verify that the user’s goal is achieved using the system
Write acceptance tests before coding
Non-functional requirements and business rules are often
captured as part of acceptance tests Are these
acceptance
Engage customer to define acceptance tests tests?
As a registered
student
• Student can access course
I want to access catalog 24*7 hours
course catalog • Student cannot choose more
content so I create than three courses
my schedule
Agile Requirements at Scale 11
13. Why use User Stories?
Right size for planning, works for iterative development
Defer detail until you have the best understanding you are going to have
about what you really need
Focus on user goals and business values
Emphasize verbal rather than written communication
Comprehensible by both Stakeholders and the dev team
Stories support evolutionary development
Agile Requirements at Scale 13
14. Definition of Done
Every story needs to meet this definition to be counted
Start with a manageable definition of Done
Review definition of Done each iteration, try to add to it
Done
No Sev 1, Sev 2, Minimal Sev 3, Sev 4
Code reviews completed
80% Unit test coverage
Test automation completed
Documentation complete and reviewed
Agile Requirements at Scale 14
15. Putting everything together: Iteration Planning
Ve locity ~ 20 Product Backlog Size
60
As a customer I want to be 5
50 As a customer I want to be 3
40
As a administrator I want 2
Velocity of ~20,
Rank Order
St ory Point s Target ed
30
St ory Point s Co mplet ed
20 Select top 5 As a business planner I 3
10
stories (21 pts) As a customer I want to be 8
0
It erat io n 1 It erat ion 2 It erat io n 3 It erat ion 4 It erat ion 5 As a administrator I want 2
As a product owner I want 5
As a customer I want to be 1
As a customer I want to be 8
Iteration Planning
1. Pull stories from the top of your ranked list
2. Use the team velocity to determine how many stories to include in iteration
Velocity = total story points completed on average over last ~ 3
iterations
3. Define Acceptance tests
4. Define the tasks required to complete the work
Agile Requirements at Scale 15
16. 1
6
Agenda
1 Agility and requirements
2 Achieving better Requirements on
agile projects: User stories and
beyond
3 Brief introduction to Agile requirements at scale
4 Conclusion
Agile Requirements at Scale 16
17. Agile scaling factors
Team size Compliance requirement
Under 10 1000’s of Critical,
developers developers Low risk
Audited
Geographical distribution Domain Complexity
Straight Intricate/
Co-located Global -forward Emerging
Disciplined
Enterprise discipline Agile Organization distribution
Project Enterprise
Delivery (outsourcing, partnerships)
focus focus Collaborative Contractual
Organizational complexity Technical complexity
Flexible Rigid Heterogeneous,
Homogenous Legacy
Agile Requirements at Scale 17
18. Things to consider when you are scaling?
Features , Use Cases, or User Stories
How much discipline?
Automation is the rescue?
Need additional level of planning?
Documentation?
Reviews? Drive
Agile Requirements at Scale 18
19. Use Cases or User Stories? Use Context
A use case is A user story is
the specification of a set of actions a simple, clear, brief description
performed by a system, expressing a user’s goal for
which yields an observable result that using the system under
is, typically, development
of value for one or more actors or other to deliver business value
stakeholders of the system. (Unified
Modeling Language - UML 2.0)
Both methods are focusing on users and values to the users.
Each has its own strengths and weaknesses.
How do we bring together the best of the both worlds for Agile
Requirements at Scale?
Agile Requirements at Scale 19
20. Scaling factors make Agile hard? CLM to the rescue
Agile planning 101 Prioritized/ranked
Master story List Requirements List
Add user
Create profile
Book reservation
Te
am
Make payment ve
lo
cit
y
Continual Stories
Defects
Improvement
Collaboration
Sprint
Test Scripts
Builds
Visibility to the Lifecycle traceability
whole team
Agile Requirements at Scale 20
21. Agile requirements and large teams
Communication and coordination risk increases with large teams
Initial requirements and architecture envisioning is critical
Coordination of requirements between subteams is important
Team organization, architecture, and requirements must reflect each other
Re-enforce the usage of product backlog for scope management
Use simple tools, apply some agile practices such as active participation of
stakeholders
Agile Requirements at Scale 21
22. Agile requirements and regulatory compliance
You may need to adopt other requirements
strategies, such as use cases or formal System
Requirements Specifications (SRSs)
BUT... read the regulations, because they likely don’t
specify how, nor when, to capture the requirements
Traceability is often a secondary, but important,
part of the regulation
BUT read the regulations, because they likely don’t
specify the level of detail required
You will likely need to write more documentation,
particularly business rules and requirements
pertaining to sensitive data
BUT read the regulations, because you only need to
do this to the extent of the risk of the project
You may need to hold reviews
BUT read the regulations, because they seldom
require formal reviews
Agile Requirements at Scale 22
23. Agile requirements and geographically distributed
development
Geographically distributed teams incur
significant communication risk
Need a more “disciplined” agile
requirements approach
One that can address risks
Automation is a “must” for requirements
traceability, version control and
collaboration
Requirements dashboards and reporting
on certain important measures become
necessary
Large team considerations apply
Agile Requirements at Scale 23
24. Agile requirements and domain complexity
Business process sketching may help
understand the complex domain
environment Rich-text,
Images, links
Process
Might want to consider light-weight use Sketches
cases instead
Will likely need to do more user interface
(UI) prototyping
Active participation of stakeholders
Shared
throughout the life cycle is crucial for you Glossaries
to understand their changing needs
Feedback and
Important: Complex domains don’t imply Dialogue
that you need detailed requirements
speculations UI Sketches and
Use Cases Storyboards
Agile Requirements at Scale 24
25. 2
5
Agenda
1 Agility and requirements
2 Achieving better Requirements on agile
projects: User stories and beyond
3 Brief introduction to Agile requirements at scale
4 Conclusion
Agile Requirements at Scale 25
26. Implications for Business Analysts (BA)
The BA goal is to build a shared understanding, it isn’t to write detailed
documentation
Expand your horizons and become a generalizing specialist
Learn how to perform acceptance TDD so that you can capture requirements as
executable specifications
Recognize that one process size does not fit all, that you will need to be flexible
Your primary goals should be to:
Facilitate communication between stakeholders and developers
Put developers in direct contact with stakeholders wherever possible
Help developers learn better communication skills
Agile Requirements at Scale 26
27. Implications for Organizations
Don’t be fooled by the agile rhetoric
You still need to invest in modeling
You still need to invest in requirements management
Don’t be fooled by the traditional rhetoric
Detailed documentation adds risk to IT projects
Individual teams find themselves in unique situations, so will have
unique tailorings of your process
Agile Requirements at Scale 27
