-
Scrum Requirements
Techniques for User Story Definition and Sizing
Victoria Hall Sr. SW Engineering Manager Bio-Rad
Laboratories
[email protected]
-
About Me
Software development & management
Agile background, CSM, CSP, internal coaching
Released numerous multi-tiered web and enterprise systems,
concentrated in last ten years on bioinformatics and biological
sciences
External Scrum educator and consultant but
I am not writing a book
-
About Me
What Im not A Product Owner But, Ive played one
I mentored numerous product owners who are new OR young OR water
fall-ish OR ALL OF THE ABOVE
And taught them about Agile and Scrum and their roles and
duties.
-
Why this talk
I expect most of us have struggled with developing stories that
are:
Meaningful Right sized Right described for the planning stage
that we are at.
Lets share our experiences and discuss some new ideas.
-
About you
How many Product Owners here?
How many Scrum masters?
Any other roles?
What size teams?
How many years experience?
Any questions I should keep in mind as I go through the talk
that people have been burning to have answered?
-
T O P I C S
Introduction to User Stories
Right Sizing User Stories The Last Responsible Moment Estimation
Velocity
Defining User Stories
Micro-planning discussion
Closing
-
Introducing User Stories
Why user stories?
What does a user story look like?
Generating User Stories
Intro to User Stories
-
Why User Stories?
Software is about translating ideas into reality
What possible ways can we communicate ideas?
-
Skywriting.
-
Others?
Written
Verbal
Music
Multi-media
Video
-
Why User Stories?
Written communications Provide a permanent record Can be more
easily shared with groups and remote
personnel Can be well thought out and thorough Can be easily
misinterpreted
Verbal communications Immediate feedback Dynamic Easily adapts
to new developments May spark new ideas Easier to reach common
understanding and clarity
-
Why User Stories?
User stories combine the strengths of BOTH written and verbal
communications
Provide some documentation but more important to encourage
discussion. Foster interaction Easy to right size Independent
Facilitate planning and implementation Gets customer bought into
the process and the product Encourages deferring of detail Works
for iterative development
-
What is a User Story?
What kinds of things do your teams typical User Stories
contain?
A statement of what value a user will get from using your
software A listing of alternative paths related to the initial
story Acceptance criteria Possible exceptional conditions and
responses that the user should experience An owner An estimate A
section to capture any discussion & decisions made
-
An example
Consider a source control system
Possible user story As a developer, Id like to examine the
differences between my development tree and the main repository in
order to evaluate what integration issues I need to consider.
Acceptance criteria The user interface displays a report of the
format below (see picture) that shows the differences between my
tree and the main tree.
Exceptional criteria If the main repository is unavailable, the
developer should see a message that says, The repository server is
unavailable. Please correct the problem and try again.
-
Use Pictures
Picture of potential UI Keys called out below!
List of file differences Summary listing
Icons showing different states
-
An example
Limitations paths The developer does not have to indicate which
tree is theirs only the default developer tree will be evaluated.
The report does not have to be navigable at this time.
Alternatives none.
Owner Ms. Product Owner
Estimate 80 team points
Discussion Eventually the developer should be able to indicate
any tree for comparison with the main repository. This will be
deferred to a future User Story. The layout suggested is only a
starting point, please let me know what is possible given
everything else weve got going on.
-
What is a User Story?
More formally A User Story has three elements
It answers the questions Who?, what? and why?
It takes the form of As a [user role] I want to [do something in
the software] so that I can [statement of value]. Example:
As a clinical biologist I want to discover biomarkers so that I
can develop a clinical diagnostic for sepsis.
As a real estate agent I want to post a notice for a house that
I have for sale in order to allow potential buyers to look at
it.
-
Generating User Stories?
How do your teams generate user stories? User Stories are
written and owned by the customer.
Ideally this is an actual user or users of the software
More practically it is a user proxy Product manager Business
analyst Development management
Some proxies are better than others why?
-
Generating User Stories?
If you end up with a committee of users or user proxies, what do
you do?
What if your user is inexperienced in software development and
requirements generation?
Training Collaboration w/ development usu. Scrum master
Investment is important
-
Generating User Stories?
Other techniques Sales Technical support User surveys User group
meetings Customer visits and observations
These can help but are no substitute for an actual person to
collaborate with.
-
You have your product owner you may even have a pile of stories
Now what?
Its really important to right size stories given the stage of
planning.
How much information is too much?
How much is too little?
Right Sizing User Stories
-
Let the horizon be your guide
Vision
Epics
Stories
Tasks
Tim
e un
til
impl
emen
tatio
n
2-4 weeks
3-6 mos
6-12 mos
granularity
-
The Last Responsible Moment
Requirements churn is bad
What is meant by the last responsible moment?
Make decisions at the last responsible moment - the point at
which failing to make the decision eliminates an alternative.
Knowledge of the lead times required for realizing design
alternatives is necessary in order to determine last responsible
moments
-
An Extreme Example
Say youre a penguin being chased by a seal.
-
Time Boxing Decisions
A military officer who was about to retire once said:
The most important thing I did in my career was to teach young
leaders that whenever they saw a threat, their first job was to
determine the time box for their response. Their second job was to
hold off making a decision until the end of the time box, so that
they could make it based on the best possible data.
An introduction to Lean Software Development by Mary Poppendieck
Interviewed by Gustaf Brandberg Copyright 2004 by Citerus AB,
Sweden (http://www.citerus.se). This work is licensed under the
Creative Commons Attribution License 2.0
(http://creativecommons.org/licenses/by/2.0).
-
How to right size?
In order to right size you need to accurately assess your
planning horizon you need to know how large a story is and to know
how much your team can get done in a period of time.
The former is estimating the latter is velocity.
-
Estimating User Stories Story points Estimating techniques
Velocity Epics, releases, iterations and tasks
Estimating
-
Estimating
How do you define story points on your teams? A measure of
complexity and size of a feature or features relative to others FOR
YOUR TEAM Can be
Ideal programmer days or hours A totally unrelated to time
measure
(e.g. agile points, liters, happy days)
-
Estimating
They must be
Consistent for your team assuming your team is constant
Understood by your team Able to be scaled discretely relative to
the actual size and complexity of the tasks, stories, epics your
team will be estimating
They do not scale with whos on the team or the tools they may
choose.
Or do they??
-
Estimating example
Taking inventory of your library
-
Estimating Techniques
Estimates are derived by the team collaboratively why?
To build consensus To build ownership To add information To add
accuracy
What ways do your teams estimate and reach consensus about those
estimates?
Triangulation Fist of five Polling
-
Estimating Techniques - Triangulation
Even when you know nothing you know something Is this story
bigger than X? Is this story smaller than Y? What are peoples best
guesses on size? Can we reach a consensus? Do we have a history of
performance on similar sized and complex features?
-
Estimating techniques Polling (aka planning poker)
What is consensus? I can live with and support that.
Each team member writes down (or holds up) what they think the
story will take independently.
Estimates are revealed High and Low estimates are defended. New
information is likely revealed.
User story is adjusted. Re-vote and repeat until consensus is
reached
-
Estimating techniques fist of five
An estimate is developed somehow and posted for the given
story
The teams votes on the estimate (1-5) 1 is I strongly disagree 5
is I strongly agree
1s and 2s explain their positions, we adjust the user story or
share new information and we vote again.
Once everyone gets to 3 or more we declare that we have a valid
supported estimate.
-
Estimating Techniques
A example from the financial world As a financial analyst, I
want to predict consumer loan performance for the next year in
order to decide how much reserve I must safely maintain to cover
defaults. As a financial analyst, I want to capture a single
geographic markets labor data as published by the regions Labor
Dept (e.g. Total non-farm payroll from the US Bureau of Labor
Statistics) so it can be used in future time based analysis. As a
financial analyst, I want to capture multiple regions economic data
for the last ten years in order to train the analytics engine that
predicts consumer loan performance.
-
Estimating Techniques
We would all agree The first one is too big to be accomplished
in one iteration even with the best and brightest team. It is
simply too complex. The second one can be accomplished probably by
one person in something less than an iteration provided
infrastructure is in place The third one may be a good 1-2
iteration goal. If its more than an iteration, considering breaking
it down even further.
-
Velocity The measure of how much your team can accomplish in an
iteration It takes the form of
Story points / iteration Iteration usually equals 1 Story points
are only story points actually completed
not partially completed
This is the bit that should change depending on whos on the team
and what tools they use.
Velocity
-
Velocity
Velocity is an unknown with A new team A new project Any time
someone comes onto team or is re-assigned off of the team
Educated guesses are fine initially
Or Run a sizing iteration whose main purpose is to help the team
get a measure of its velocity in order to better plan future
iterations.
Especially helpful in contract work if it can be arranged.
Eventually your team will understand how much they can accomplish
in an iteration and how that relates to whatever pointing system
they are using.
-
Velocity
How do you measure velocity?
Why do we only count stories actually completed in the
velocity?
How would we measure a fractionally completed story? Most
importantly if something is not complete it usually cannot be used
therefore may not be of value to the end user or business. It
doesnt count if its not DONE. If stories are routinely partially
completed, they are probably too big for your team.
-
Sizing For The Horizon
Depending on where we are in the planning process the size of
user stories must be different.
Remember velocity helps us determine the appropriate planning
horizon and estimates give us a way to determine whether we are
discussing things in the proper granularity.
-
Sizing For The Horizon
Epic Stories these are your largish user stories. Are written
whenever discovered but are usually tackled within a release time
frame. This is typically 3-6 mos. This may be different for your
team They are often aggregate user stories that are compounded or
of sufficient complexity that they must be broken down.
-
Sizing For The Horizon
User Stories this is the most commonly sized user story
Again, they can be written whenever discovered but contain only
enough detail to be a place holder if they are scheduled for later
iterations. As they are scheduled for nearer iterations, the level
of detail should increase. If they are scheduled for this
iteration, they need to have enough detail to begin implementation
discussions. Time horizon 2-4weeks
Tasks this is where a user story ends up once its been slotted
for an iteration and needs to be implemented.
Time horizon hours - 2 days
-
Its all relative.
-
G.U.S.
Good User Stories
-
Good User Stories (GUS)
How do you tell if a user story is GOOD?
Describe what users DO in easy to understand language
Instigates discussion
Take a slice through the whole system
Represent acts that can be completed
Capture constraints and limitations
Explicitly state dependencies, if known
Are written by the customer
Can be estimated; can be validated
-
Good User Stories
What do you want to do today? Choose stories that describe
something that your users will ACCOMPLISH with your software List
these for each user role for your software These may be large at
first
E.g. Locate the perfect home for my family or Edit a movie
Consider these as starting points if they are too big, break
them down
-
Good User Stories
Take a slice through the system. If a story is too big, break it
down on natural system boundaries.
Do a less complex but useful version first A real estate agent
can submit a home that includes
only geographic area and property number. A movie editor can
identify and save key frames.
It is functionality that touches all parts of the system but can
be done in an iteration.
-
Good User Stories
Write closed stories- stories that end with the achievement of a
meaningful goal.1
Instead of a home seeker can maintain her search criteria.
A home seeker can create her search criteria A home seeker can
review the results from a
search. A home seeker can change the geographic area for
her search criteria.
1. Cohn, Mike User Stories Applied. 2004 Pearson Education
-
Good User Stories
What a system should not do is as important as what it should
do.
Write down constraints and limitations such as
Technology Dependencies Performance Platforms Tools Whatever
else you can think of that matters
-
Good User Stories
Good user stories are written by the customer
What if they wont or cant? Help them to do it
Write stories that are dictated Suggest stories if they are
stuck Collaborate on new stories if they cant decide
If you help, dont do it for them. As much as possible, get them
to be involved and owning what the software is supposed to
accomplish Teach, mentor, coach.
-
B.U.S.
How do you tell if you have a bad user story? Bad User
Stories
-
BUS Indicators
Platinum plating
Too small
Too big
Interdependent
Including the UI too soon
Thinking too far ahead. Classic!
When stories become tasky see too small
Customer cant prioritize
Too many details to fit on a card or card proxy
-
BUS Mitigation
Platinum plating The user story is
A biologist can view the instrument data in a landscape plot
that is scrollable and scalable.
The platinum plating would be A biologist can view the
instrument data in a plot
whose aspect is configurable that is scrollable and scalable and
zoomable and may change color.
We want to give users more than they ask for. Resist the urge.
It takes time to implement, test and document things that the user
didnt ask for and may not need.
-
Breaking things down
How do we know a story is too big? Not estimated to fit in one
iteration. Team is repeatedly moving partial stories out of an
iteration into the next one.
What do we do about it? Break stories down. This also applies to
place holder stories once you get to planning.
-
Breaking things down
Techniques for dividing up a user story that is too large
Disaggregate along data boundaries
-
Breaking it down
Other techniques Break complexity down by time boxed phases
Investigate Implement
Break a story down into its compound elements Creation, editing,
removal, maintenance as a
combination of all three Insert, update, delete from the
database side of things
-
Building it up
How do you know if you have a story thats too small? Usually its
finished in a very short amount of time. Its too simple to be
useful by itself Your team finds that its forgotten lots of
important things that contribute to done-ness
-
Building it up
If a story is less than a day of work, consider combining it
with another related story.
Dont forget the little things these may be ongoing maintenance
kinds of things
Defect fixing Documentation Regression test updates User
interface tweaks
They all take time and should be planned for.
-
Creating Independence
If a user story depends on too many other user stories being
completed, it is not independent enough.
Does anyone have a good rule of thumb for too many
dependencies?
What do you do about it? Maybe you need a hierarchy and not a
chain (or web) of dependencies? It may need to get bigger. It may
need to get smaller.
-
If short iterations are good, are shorter iterations better?
Software development can be thought of as a series of
analyze-code-build-test cycles.
Every large section of software will pass through this cycle
(many times), but so will every small section of code. A developer
may go through these steps several times a day, or even, many times
per hour
If a requirement is not being used, it is in process inventory
This is waste. The idea of continuous flow and the least
responsible moment fit nicely.
Can we do better than traditional SCRUM?
Micro-planning
-
Increase Utilization
If we look at reduction in cycle time relative to utilization
and assume that high utilization is good.
Mary and Tom Poppendiek
-
Reducing Cycle Time
Queuing theory gives us six rules for reducing software
development cycle time: 1. Limit work to capacity
2. Even out the arrival of work
3. Minimize the number of Things-in-Process
4. Minimize the size of the Things-in-Process
5. Establish a regular cadence
6. Use pull scheduling
-
For your consideration
So if you want high utilization and low cycle time, you should
develop in very small batches. For example, you will get much
faster throughput and higher utilization if you develop ten
services one at a time, rather than developing all ten at the same
time.
Can we develop in 1 day iterations?
What would the user stories look like?
What are the challenges?
-
Closing
Introduction to User Stories
What is a User Story
The Last Responsible Moment
Developing User Stories
Right Sizing User Stories
Micro-planning
Have we answered all the questions?
