gathering agile requirements -...
TRANSCRIPT
Gathering Agile Requirements Dan LeFebvre Agile/Scrum Coach, CSC © DCL Agility, 2010-2012
1
6/7/2012 Agile Boston
Dan LeFebvre Founder & Agile Coach,
DCL Agility, LLC
Certified ScrumMaster (CSM), Certified Scrum Professional (CSP) Certified Scrum Coach (CSC)
Extensive experience in software product development as a developer, manager, director, and coach
Using agile practices since 2003
Fulltime Agile Coach since 2006
2
11/22/2011 Give Thanks for Scrum 2011
Learning Objectives
Overview of Agile Requirements
Review: User Stories, Story Points, Estimating and Planning
Using Personas
User Story Mapping
How to Make Sense of Requirements As a Team
How to Facilitate a Product Backlog Workshop
11/22/2011 Give Thanks for Scrum 2011
3
Traditional Approach
Constraints Requirements
Estimates Schedule Cost
Plan Driven
The Plan creates cost/schedule estimates
Traditional
Always
7%
Often
13%
Sometimes
16%
Rarely
19%
Never
45%
Functions used in a Typical
System
Source: *Standish Group Study Reported in 2002
4
Traditional Approach as Envisioned
5
Customer knows what he needs
Developer knows how to build it
Nothing changes along the way
Source: Henrik Kniberg.
Traditional Approach in Reality
6
Customer discovers his needs
Developer discovers how to build it
Many things change along the way
Source: Henrik Kniberg.
What We Need is a Guidance System
7
Frequent checkpoints Customer clarifies his needs Developer improves how it’s built Adjustments along the way
Source: Henrik Kniberg.
Mindset Change
Constraints
Estimates
Requirements
Schedule Cost
Plan Driven
The Plan creates cost/schedule estimates
Traditional
The Vision creates feature estimates
Schedule Cost
Features
Value / Vision Driven
Agile
Source: Michelle Sliger in “Relating PMBOK Practices to Agile Practices”
8
Release Planning Steps ② Estimation
③ Ordering ④ Projection
① Definition
9
Product Backlog
Ordered list of everything that might be needed in the product
Owned by the Product Owner
Responsible for contents, availability, ordering
Is never complete as long as the product exists
Starts with known, understood requirements
Evolves over time
Sized by the development team
10
What are Product Backlog Items?
Features, functions, technologies, enhancements, and bug fixes
Analysis
Design
Code
Test
UI
API
Server
DB
HO
W
Backlo
g Item
Backlo
g Item
Backlo
g Item
Backlo
g Item
Backlo
g Item
Backlo
g Item
Backlo
g Item
WHAT
11
Product Backlog
Physics
• Product Owner owns and orders the Product Backlog
• Anyone can add to the Product Backlog
• Adopt a best practice: “If it’s not on the Product Backlog, then it doesn’t exist.”
12
Just in Time Elaboration
Spring
Cleaning
Wash Windows
Clean garage
Rake Lawn
Rake Back Yard Rake Front Yard
13
User Story
A description of a user requirement or need
Focus on CCC
Card – Small enough to fit on an index card
Conversation – Reminder for Development Team and PO to have a conversation
Confirmation – Conversations are captured in the form of Acceptance Criteria
14
Source: “Essential XP: Card, Conversation, Confirmation” – Ron Jeffries
INVEST in User Stories
ndependent
egotiable
aluable
stimable
ized properly
estable
15
Source: Bill Wake.
User Story as a Boundary Object
16
Business knows what they’ll get
Developers know what to build
Artifact to drive the plan
Governance has traceability
The User
We often make the mistake of assuming there’s only one user for a project - “The User”
17
• Stories are written from one user’s perspective
• We assume all users have the same goals
• Leads to missing stories = LOST VALUE
User Roles
Different types of end users may interact with the system differently.
Unique perspectives change requirements and acceptance criteria
Who are the users of our system?
What are their goals and objectives?
How do they use the software?
What are their priorities?
18
User Personas
A User Personas is a specific detailed description of a user type designed to make the user real.
Similar to ‘avatars’, personas stand in for real users
We aim to understand the characteristics, needs and behaviors of personas to help us map out specific requirements that fulfill their objectives.
Usually given name and face and is described in detail with goal to identify someone to design for.
Copyright© Agile Transformation Inc
19
User Personas - Example
21
Ryan (Job Seeker)
- Needs to find work
- Looking for training to help
get up to speed or provide
an edge
- Thrifty, wants a deal
Dwight (Ladder Climber)
- Ambitious
- Wants to move up the
chain
- Willing to spend
- Looking for training
that sets him apart
Jim (Corp. Employee)
- Wants to succeed in job
- Takes training as needed
- Time is valuable
- Opinionated
Michael (Manager)
- Cares about employees
- Wants them to be successful
- Concerned about cost
- Wants to be involved, see
results, metrics, etc. Dunder Mifflin (Partner)
- Wants exposure
- Willing to spend for
potential customers
- All about profits
- Demanding
Exercise
Work in small groups of 3 or 4
You are responsible for gathering requirements for a job seeking website
Create a few personas for users of our system
11/22/2011 Give Thanks for Scrum 2011
22
User Story Mapping
A way to visualize your initial backlog
A way to share this view with others
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
User Story Mapping
Your Product Backlog has a backbone
You can visualize it
You can WALK it with others to validate it, and develop it further
http://www.NewTechUSA.com
© Copyright 2002: All rights reserved
User Story Mapping
Visual depiction allows a “shared model” held by everyone at once
Exercise
Think of the job-seeker
What are the activities they want to do with the system?
Place them on separate cards as user stories
11/22/2011 Give Thanks for Scrum 2011
26
Exercise
Select 1 activity
Ask one person to describe the tasks the job-seeker needs to do to accomplish the activity
Someone else writes a card for each task
If you hear the word “THEN” then place the card to the right of the previous one
If you hear the work “OR” put the card below the previous one
11/22/2011 Give Thanks for Scrum 2011
27
How much time should we spend on
estimating?
28
131 ?
?
?
Not as Much as You Think
29
Estimate Size – Derive Duration
30
Size Rate Duration
240 Miles 60 MPH 4 Hours
180 Story Points
30 pts/iteration 6 Iterations
Story Points
Story Point size represents
Complexity – How hard is it?
Volume – How much is there?
Knowledge – What do we know?
Uncertainty – What’s not known?
Unit-less but numerically relevant
Relative values important
Helps calibrate development team members
31
Great for large number of stories to be sized (>15)
1 2 3 5 8
Affinity Estimation
33
Source: http://www.gettingagile.com/2008/07/04/affinity-estimating-a-how-to/
Smaller Larger
Requirements as a Team Activity
Remember CCC
Take entire team on the journey of discovery together
Remember Just-in-Time Requirements Elaboration
11/22/2011 Give Thanks for Scrum 2011
34
Product Backlog Refactoring
Product Owner responsible for properly preparing the backlog
Team allocates 5%-10% of Sprint time to help the PO prepare for next sprint
Never allow the Product Owner to go into the Sprint Planning meeting with an inadequate Product Backlog
35
Potentially Shippable Product
Increment
36
Started Done
Mindset Change
Constraints
Estimates
Requirements
Schedule Cost
Plan Driven
The Plan creates cost/schedule estimates
Traditional
The Vision creates feature estimates
Schedule Cost
Features
Value / Vision Driven
Agile
Source: Michelle Sliger in “Relating PMBOK Practices to Agile Practices”
37
Allows Stopping Whenever We Have
Enough Value Backlog Item Points 1. Login portal 5
2. Display minutes 3
3. Support ticket call 8
4. Remote login help 13
5. Update profile 2
6. Buy more time 8
7. Single sign-on 20
8. Log rotation 5
9. Timer display 3
10. Automatic logout 1
11. Usage warning 2
12. Exchange 12 integration 13
13. HP Openview API 20
14. XML API 8
15. 300 logins/min 13
16. Location tracking 5
17. Intrusion detection 13
18. Update MySQL DB 20
19. Update Web Stack 13
20. Update Linux Kernel 8
21. Support Novel Auth 13
22. Support RADIUS Auth 8
23. Scan & Block Int. 40
24. AP Manager Int. 20
Release
Plan
What can we
accomplish given our
constraints?
38
So We Avoid Over-Production
Always
7%
Often
13%
Sometimes
16%
Rarely
19%
Never
45%
Functions used in a Typical
System
Source: *Standish Group Study Reported in 2002
39
40
11/22/2011 Give Thanks for Scrum 2011