1. *
Relative Sizing
What is a Story Point?
Points vs Days?
Why Story Points?
What is Velocity?
How to establish Story Points?
Story Point Assignment
Release Planning with Velocity
2. *
*To express the overall size of an
object by comparison to the size of
a another known object.
*Example: An object of size 6 is three times the
‘size’ of an object size 2, but we have no gauge
what an object of size 2 is in the absolute
sense.
2
2
6
3. *
*A relative size used to represent
the estimate for a user story in the
product backlog
2
3
5
8
13
20
4. *A story point does not
change over time depending
on team performance
*A story point is relative
* Example: A user story of 8 Story
Points has been estimated by
the sprint team.
* Since the estimation was
given, the sprint team
learned a lot and is now
performing at a very high
level
* The user story remains at an
estimation of 8
*Ideal days change over time
based on team performance
*Ideal days are absolute but
often used relatively
* Example: A user story of 14
days has been estimated by the
development team.
* Since the estimation was
given, the sprint team
learned a lot and is now
performing at a very high
level
* The user story estimate of
14 days is now inaccurate
*
5. *
*A Story Point doesn’t change over time
*Simplifies estimation by using the Fibonacci
sequence (0,1,2,3,5,8,13…) allowing the Sprint
Team to focus on complexity
*Story Points take into consideration differences
in team experience levels
*Commitment is removed from the estimation
process and done during Sprint Planning when
the team is ready to commit
*Collaboration of the entire Sprint Team is
required
6. *
*The average number of Story Points
a Sprint Team can complete within
an iteration
0
2
4
6
8
10
12
14
16
18
20
Sprint 1 Sprint 2 Sprint 3 Sprint 4
7. *
* Story assignment must take into consideration:
* Knowns and unknowns
* Complexity
* Overall effort
* Risk
* Story assignment does not take into consideration:
* Which team members will be doing the work
* Time needed to complete the work
* All Sprint Team members participate in the sizing decision
* Create a 2 baseline stories, these are stories that have been
completed previously and can be given a story point
* Pick an example of the smallest story the team would work
on, assign it the Story Point = 1
* Pick an average story the team would work on, not too big,
not too small which can represent a middle point
* Decide what your Story Point scale is going to be within the
Fibonacci sequence (0,1,2,3,5,8,13,20…)
8. *
*Relative sizing using the baseline stories through
planning poker is a common approach to Story Point
assignment
*Planning Poker
* Scrum Master facilitates a Story Pointing session
* Product Owner reads the story to be sized and answers
any preliminary questions the sprint team may have about
the story
* Baseline stories are reiterated so sprint team members
can relatively size the new story
* Each team member chooses their point (often in the form
of a card laid face down)
* Scrum Master calls for team members to expose their
points simultaneously
* Discussion takes place for high and low estimates
* The process is repeated until a group consensus can be
reached
9. *
*A product backlog can be broken into sprints to
plan a release by using the sprint teams
velocity
*A release can be planned by date or by feature
set
*The product backlog is always in priority order
based on what the intention of the release is
10. *
*A sprint team with a velocity of
25 could have a backlog like this
*If an iteration is 2 weeks, by date
we know which stories will make
the release in 6 weeks
*If an iteration is 2 weeks, by
feature set, we can determine
how many sprints are required to
complete the stories within the
feature set
Most of these stories are too far out
and too large to consider into the
current release without further
breakdown
11. *
*A release burndown chart can be kept to
measure the current release of a sprint team
*Using the planned Story Points and actual
velocity
75
45
23
0
10
20
30
40
50
60
70
80
90
Sprint 0 Sprint 1 - 30V Sprint 2 - 22V Sprint 3 - 24V
PlannedStory
Points
Release 1 - Velocity Average 25
12. *
*A release burndown chart can be kept to
measure the current release of a sprint team
*Using the planned Story Points and actual
velocity
75
45
23
0
10
20
30
40
50
60
70
80
90
Sprint 0 Sprint 1 - 30V Sprint 2 - 22V Sprint 3 - 24V
PlannedStory
Points
Release 1 - Velocity Average 25
13. * For more Agile information please
visit our website
www.agiletestingframework.com
*
Editor's Notes
Notes
The concept of relative sizing can be difficult at first
By comparing the new story with a known story of size, the size of the new story can be estimated by comparison
Notes
The concept of relative sizing can be difficult at first
Assigning a size to a story must take into consideration knowns, unknowns, complexity, overall effort and risk
The Fibonacci sequence is used to account for inherent uncertainty as the stories get larger, the larger the story, the more uncertainty, the less accurate the estimate
The Fibonacci sequence also limits the number of choices causing the sprint team to collaborate and agree within the chosen scale
Notes
Story points remain accurate over time unlike idea days
The use of story points with the Fibonacci sequence limits the choices and is therefore faster leaving the team to focus on the story details
As a sprint team matures and becomes more efficient, more stories can be taken into an iteration for completion, but the story point estimation of a story has no reason to change and is accurate
Ideal days often given relatively but used absolutely. 3 ideal days can mean many things to many people. 3 days on a calendar for 1 person is different than 3 days on a calendar for 2 people or 3 days on a calendar for a senior person vs a junior person.
Ideal days often insinuate commitment, story points do not as they are unit-less
Notes
Story points are more accurate over time as they do not change.
Using the fibonacci sequence allows the sprint team to have known choices of estimation assignment which speeds up estimation agreement, promotes less variation and more accuracy when sizing stories against other known stories
Release planning becomes simple as story points become consistently accurate per sprint team
Points are unit-less with no commitment associated with them at time of estimation leaving the commitment where it belongs at Sprint Planning
The sprint team as a collective group discuss each story and discuss the story point size giving the group an understanding of all efforts required for a story
Notes
At the end of each sprint iteration, the number of completedaccepted user stories contribute to the overall sprint team velocity.
As sprint teams change, become more experienced, lose members, gain members, the velocity will be adjusted. It is self correcting.
The velocity is used to determine the average number of story points a team can complete within a normal iteration.
Notes
Assigning a size to a story must take into consideration knowns, unknowns, complexity, overall effort and risk from the perspective of different team members (technically, testability, data volume, environmental factors, proven vs unproven details etc)
All team members participate in deciding what size assignment a story will get
There is no time associated with the size of a story or a story point, story points are unit-less
There is no consideration as to whom may do the work, because we do not know, and although a senior person may complete a story faster, remember, there is no time associated with a story point, therefore it has no bearing during story point assignment
Notes
A sprint team’s baseline stories are reiterated at the start of a story pointing session to re-align the team members
The Scrum Master will facilitate the session to gain group consensus
The Product Owner reads and answers questions regarding the story being pointed to help the sprint team provide their estimate
The Scrum Master must facilitate the session to avoid the sprint team from going ‘too deep’ into details during this session, the sprint team needs enough information to provide the story point based on what is known today, implementation details are not required
Exposing the story point simultaneously is important, it allows each team member to provide their estimate without influence of others
The team members should provide their first estimate quickly so that points that differ drastically can be discussed to shed light on a team members concerns houghts
The Scrum Master will have the team repeat the process and remind them often of their baseline stories to encourage relative sizing techniques
Only sprint team members get to decide a Story Point for a story as they are the people who will be doing the work
Notes
At the end of each sprint iteration, the number of completedaccepted user stories contribute to the overall sprint team velocity.
As sprint teams change, become more experienced, lose members, gain members, the velocity will be adjusted.
The velocity is used to determine the average number of story points a team can complete within a normal iteration.
Notes
A Product Owner can use a sprint team’s average velocity to release plan by date or by feature set
The product backlog is ordered in priority
If planning by feature set, the feature set stories will be at the top of the product backlog as they will be priority
If planning by date, stories from many different feature sets will be at the top in order of their priority
The product backlog is broken into sprints by using the sprint teams average velocity
If planning by date, knowing the iteration cycle of the sprint team, a Product Owner can clearly see what will be delivered by a given date
If planning by feature set, knowing the iteration cycle of the sprint team, a Product Owner can clearly see how many sprints are required to delivery the stories required to fulfill the feature set and determine the release date
Release planning is an ongoing cycle, at the end of every sprint, the team will recalculate their velocity and the Release plan can be adjusted
Notes
At the end of every sprint iteration, the total number of completed story points is added to create the velocity of that sprint
The average velocity for the sprint team is readjusted
Using the actual story points completed, we can reduce the planned release story points and clearly see if the release is on track
Stories get added and removed from releases, this can also be reflected in the release burndown chart with adjustments to the overall planned story points
Clearly gauging where a release is at the end of every iteration allows early intervention when the release gets out of line and set expectations of stakeholders earlier in the process
Examples of early intervention can be:
Removing some stories from the release if the release is behind schedule
Re planning the date of the release to release later or earlier
Adding additional stories if a release is ahead
Giving some stories to another team
Notes
At the end of every sprint iteration, the total number of completed story points is added to create the velocity of that sprint
The average velocity for the sprint team is readjusted
Using the actual story points completed, we can reduce the planned release story points and clearly see if the release is on track
Stories get added and removed from releases, this can also be reflected in the release burndown chart with adjustments to the overall planned story points
Clearly gauging where a release is at the end of every iteration allows early intervention when the release gets out of line and set expectations of stakeholders earlier in the process
Examples of early intervention can be:
Removing some stories from the release if the release is behind schedule
Re planning the date of the release to release later or earlier
Adding additional stories if a release is ahead
Giving some stories to another team