This document discusses alternatives to using story points for estimating work in agile projects. It describes how the author's team used a simpler metric of story count instead of points to estimate the number of iterations needed to complete a mobile app. The team tracked velocity by counting completed stories each iteration rather than estimating points. This approach required less time and effort for estimation and allowed the team to focus more on completing high-value stories. The document concludes that for multi-iteration projects with trust between stakeholders, simply counting completed stories can work better than estimating points.

1. Should we stop using
Story points & Velocity?
Prasanna Vaste
Thoughtworks India

2.  Why estimate
 What most teams use (story points)
 Why story points? Does it help
 How we used story count
 How it helped
 Conclusions
 Questions

3. Why do Agile team extimate
 Track velocity
 Decide scope for the Iteration
 Help Prioritize stories
 Help Release planning

4. But In reality..
 Estimation takes lot of time and effort
 PMs/DMs tend to relate these estimates to no. of days to
complete story/feature
 In some cases estimate is equal to deadline
This results into,
lack of confidence on development team when stories take
more time to complete.

5. Claims that justify use of story
point
(Mike Cohn's book "User Stories Applied )

6. 1. The use of Story points allows us to change our mind
whenever we have new information about a story.
2. The use of story points work for both epics and smaller
stories.
3. The use of Story points doesn’t take a lot of time.
4. The use of Story points provides useful information about
our progress and the work remaining
5. The use of Story points is tolerant of imprecision in the
estimates
6. The use of Story points can be used to plan releases

7. So what we did

8. Use of simple metric
 Was asked to build mobile app to allow users to buy car
insurance
 Product owner was keen to understand the time it will
take to build MVP scope
 Team decided to not use story points for estimation
 But if no story point then what…

9. Use of simple metric
 Team wanted something simple, easy to track and
requires less time for estimation.
 We decided to use story count i.e. measure progress by
measuring the number of stories completed in an
Iteration

10. Using Story count
 Assume all stories are of same size
 Agile Velocity game to identify team velocity
 Start Iteration 1 and count actual velocity (completed cards
count)
 No. of stories in backlog / No. of stories completed
in 1 st Iteration = No. of Iterations to complete
required scope
 Relook at velocity after another Iteration and adjust the
planned velocity
 In Iteration planning meeting, used count of stories completed
in past Iteration for sign up

11. Burn up chart
using story count

12. Feature Completion Tracker

13. How Story count helped
Product owner and Team were happy with this change as:
Fewer metrics, more conversations
Less Math, more effective planning
Better way to track change in scope
More focus on completing stories which give higher
business value instead of quick gain in story points

14. Story count works best
for projects with more than 4-5 Iterations
And where there is lot of trust between Product Owner
and Development team.
Evolve your estimation process from “Story points =>
Relative sizing => Counting cards”

15. Final words
Stop wasting time trying to estimate a never ending
Backlog. There's no evidence that that will help you predict
the future any better than just counting the number of
stories "Done"!

16. Questions? Comments?
pvaste@thoughtworks.com
@prsvaste