© 2009 IBM Corporation
Agile Requirements and Context Counts
Cherifa [email protected]
WebcastAgile community in Prague
2Agile Requirements at Scale
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
3Agile Requirements at Scale
Agenda
1
4
3
2
Agility and requirements
Achieving better requirements on agile
projects: User stories and beyond
Brief introduction to Agile requirements at scale
3
Conclusion
4Agile Requirements at Scale
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
5Agile Requirements at Scale
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
Day
Iteration
Release
Product
Iteration
Day
Release
Product
Portfolio
Strategy
Most agile teams are
concerned only with
the three innermost
levels of the planning
onionSource: Scrum
6Agile Requirements at Scale
Agile brook down the barriers Prioritized
Requirement List
Agile Team Collaborates with Customer
TestsCode
Requirements
specs
Tests
Code
Master story
List
Add user
Create profile
Book
reservation
Make payment
Agile planning 101Requirements
One whole team
�Done
�Done
�Done
Silos
Velocity
+ MORE
7Agile Requirements at Scale
Agenda
1
4
3
2
Agility and requirements
Achieving better requirements on agile
projects: User stories and beyond
Brief introduction to Agile requirements at scale
7
Conclusion
8Agile Requirements at Scale
Agile Requirements Practices : How much is enough?
9Agile Requirements at Scale
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
10Agile Requirements at Scale 10
User stories: Ron Jeffrey’s 3 Cs
Record what you learn in an acceptance test.
Example:
Student can access course catalog 24 x 7 hours
Student cannot choose more than three courses
Confirmation
How to verify if the
story is done and
complete, and the
goal is achieved
Discuss the card with a stakeholder. Just in time analysis (JIT)
through conversations.
Example:
What information is needed to search for a course?
What information is displayed?
Conversation
How to achieve the
goal using the
system?
As a (user role), I want to (goal) so I can (reason)
Example:
As a registered student, I want to view course details so I can create
my schedule
Card
What is the goal of a
user
A user story has 3 parts. If it doesn't, it's not a user story.
11Agile Requirements at Scale
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
�Engage customer to define acceptance tests
• Student can access course
catalog 24*7 hours
• Student cannot choose more
than three courses
Are these
acceptance
tests?As a registered
student
I want to access
course catalog
content so I create
my schedule
12Agile Requirements at Scale
Acceptance Tests Examples
13Agile Requirements at Scale
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
14Agile Requirements at Scale
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
15Agile Requirements at Scale
Putting everything together: Iteration Planning
� 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
As a customer I want to be < 5
As a customer I want to be < 3
As a administrator I want < 2
As a business planner I < 3
As a customer I want to be < 8
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
Product Backlog Size
Ran
k O
rde
r
Velocity ~ 20
0
10
20
30
40
50
60
Iterat ion 1 Iterat ion 2 Iterat ion 3 Iteration 4 Iterat ion 5
Story Points Targeted
Story Points Completed
Velocity of ~20,
Select top 5
stories (21 pts)
16Agile Requirements at Scale
Agenda
1
4
3
2
Agility and requirements
Achieving better Requirements on
agile projects: User stories and
beyond
Brief introduction to Agile requirements at scale
1
6
Conclusion
17Agile Requirements at Scale
Domain Complexity
Straight-forward
Intricate/Emerging
Compliance requirement
Low risk Critical,Audited
Team size
Under 10developers
1000’s ofdevelopers
Co-located
Geographical distribution
Global
Enterprise discipline
Projectfocus
Enterprisefocus
Technical complexity
HomogenousHeterogeneous,
Legacy
Organization distribution(outsourcing, partnerships)
Collaborative Contractual
Agile scaling factors
Disciplined Agile
Delivery
Flexible Rigid
Organizational complexity
18Agile Requirements at Scale
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
19Agile Requirements at Scale
Use Cases or User Stories? Use Context
A user story is<
� a simple, clear, brief description
� expressing a user’s goal for
using the system under
development
� to deliver business value
A use case is<
�the specification of a set of actions
�performed by a system,
�which yields an observable result that is, typically,
�of value for one or more actors or other 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?
20Agile Requirements at Scale
Scaling factors make Agile hard? CLM to the rescue Prioritized/ranked Requirements List
Team velocity
Visibility to the whole team
Master story List
Add user
Create profile
Book reservation
Make payment
Agile planning 101
Test Scripts
DefectsStories
Builds
Sprint
Lifecycle traceability
Continual Improvement
Collaboration
21Agile Requirements at Scale
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
22Agile Requirements at Scale
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
23Agile Requirements at Scale
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
24Agile Requirements at Scale
Agile requirements and domain complexity
� Business process sketching may help
understand the complex domain
environment
� Might want to consider light-weight use
cases instead
� Will likely need to do more user interface
(UI) prototyping
� Active participation of stakeholders
throughout the life cycle is crucial for you
to understand their changing needs
� Important: Complex domains don’t imply
that you need detailed requirements
speculations
Rich-text, Images, links
Process Sketches
Shared Glossaries
UI Sketches and StoryboardsUse Cases
Feedback and Dialogue
25Agile Requirements at Scale
Agenda
1
4
3
2
Agility and requirements
Achieving better Requirements on agile
projects: User stories and beyond
Brief introduction to Agile requirements at scale
2
5
Conclusion
26Agile Requirements at Scale
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
27Agile Requirements at Scale
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
28Agile Requirements at Scale
2
8
© Copyright IBM Corporation 2010. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.
www.ibm/software/rational/agile/
Top Related