Sign up to save your podcasts
Or
Share Lightning Cast: Story Estimation – What’s the Point?
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Lightning Cast: Story Estimation – What’s the Point?
In this episode, we explore the use (and misuse) of story point estimation.
Lightning Casts are shorter episodes, sharing valuable information in 8 minutes or less.
Show Notes
Many Agile teams estimate their User Stories using story
points. When using this approach, many
teams also apply story points incorrectly.
A story point is a relative estimation of effort and
complexity. Story points have no
correlation to hours, days, or and other time measurement. Instead, it’s a tool in which you estimate
based on a comparison to other User Stories.
Some Scrum teams use story points for planning by
calculating the average number of story points completed in the last few iterations
(velocity) and pulling about that many story points worth of stories for the
next iteration.
While velocity can be a useful heuristic, always validate the
team’s confidence level in their ability to complete the planned backlog items.
The more powerful use of story points is in creating a
shared understanding through a discussion.
Below are some dos and don’ts for story point estimation.
Do
- Estimate as a team by providing all estimates at
the same time. This helps eliminate bias
and influence of other votes.Estimate the effort and complexity of the entire
story (coding and testing).Discuss the differences in votes to develop a
shared understanding of the effort and complexity.Identify and use reference stories; backlog items
with which the team is familiar to relatively size against.Estimate stories during backlog refinement.
Don’t
- Use story points or velocity to compare teams.
- Average the team’s story points to size a story.
- Argue against someone’s sizing. Instead, have a discussion about why everyone
voted the way they did.Size coding and testing efforts separately. Have the team share their estimations one at a
time. This leads to influencing other
team members and less discussion.Size during Sprint Planning.
Listen to the full episode to discover how to properly use
story point estimation.
Estimating User Stories with Story Points
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
The post Lightning Cast: Story Estimation – What’s the Point? appeared first on Mastering Business Analysis.
View all episodes
By Dave Saboe, CBAP, PMP, CSM | Certified Business Analysis Professional | Agile Coach
4.7
8282 ratings
In this episode, we explore the use (and misuse) of story point estimation.
Lightning Casts are shorter episodes, sharing valuable information in 8 minutes or less.
Show Notes
Many Agile teams estimate their User Stories using story
points. When using this approach, many
teams also apply story points incorrectly.
A story point is a relative estimation of effort and
complexity. Story points have no
correlation to hours, days, or and other time measurement. Instead, it’s a tool in which you estimate
based on a comparison to other User Stories.
Some Scrum teams use story points for planning by
calculating the average number of story points completed in the last few iterations
(velocity) and pulling about that many story points worth of stories for the
next iteration.
While velocity can be a useful heuristic, always validate the
team’s confidence level in their ability to complete the planned backlog items.
The more powerful use of story points is in creating a
shared understanding through a discussion.
Below are some dos and don’ts for story point estimation.
Do
- Estimate as a team by providing all estimates at
the same time. This helps eliminate bias
and influence of other votes.Estimate the effort and complexity of the entire
story (coding and testing).Discuss the differences in votes to develop a
shared understanding of the effort and complexity.Identify and use reference stories; backlog items
with which the team is familiar to relatively size against.Estimate stories during backlog refinement.
Don’t
- Use story points or velocity to compare teams.
- Average the team’s story points to size a story.
- Argue against someone’s sizing. Instead, have a discussion about why everyone
voted the way they did.Size coding and testing efforts separately. Have the team share their estimations one at a
time. This leads to influencing other
team members and less discussion.Size during Sprint Planning.
Listen to the full episode to discover how to properly use
story point estimation.
Estimating User Stories with Story Points
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
The post Lightning Cast: Story Estimation – What’s the Point? appeared first on Mastering Business Analysis.
More shows like Mastering Business Analysis
View all
Freakonomics Radio
32,246 Listeners
The Ben Shapiro Show
153,989 Listeners
The Economics of Everyday Things
1,643 Listeners
Business Analysis Simplified
0 Listeners