Rise and fall of Story Points. Capacity based planning from the trenches.

Mikalai Alimenkou
Mikalai AlimenkouIndependent Consultant at XP Injection
Rise and fall of story points.
Capacity-based planning from
the trenches.
Mikalai Alimenkou
@xpinjection
https://t.me/xpinjection_channel
https://xpinjection.com
Rise and fall of Story Points. Capacity based planning from the trenches.
Telegram channel
https://t.me/xpinjection_channel
Disclaimer
This talk is based on
personal experience
My expectations 10 years ago for 2020
Agile unicorn
Reality in many companies/teams
Agile unicorn
Sometimes situation is even worse
Talk “Agile anti-patterns: 10 years later”
https://www.youtube.com/watch?v=XTsf7quT2nM
#2. Story Points for Sprint Planning
WE ALL HAVE
USED IT FOR
YEARS!
Rise and fall of Story Points. Capacity based planning from the trenches.
Release planning could rely on SPs
Because this is just prediction game
The most serious issue in our industry
Capacity-driven planning
https://www.mountaingoatsoftware.com/blog/why-i-dont-use-story-points-for-
sprint-planning
Mike Cohn
Sprint Planning differs in many aspects
Requirements are READY for development, so no
uncertainty presents
If something has risk, then it is better to extract spike
from it and take for discovery with fixed timebox
Team knows HOW to implement requirements, so it is
able to split them into development tasks
Team structure, skills, experience and available
resources are 99% stable for single iteration
Rise and fall of Story Points. Capacity based planning from the trenches.
Why SP doesn’t work for Spring Planning
Specialization in teams only increases now
SP may work for “full-full-stack” teams
Confusing and dangerous for mixed team
Rise and fall of Story Points. Capacity based planning from the trenches.
Why SP doesn’t work for Spring Planning
Specialization in teams only increases with time
People are different and not everybody is so rational to
apply relative complexity estimates
Frequent situations behind Story Points
Rational VS Irrational team members
Why SP doesn’t work for Spring Planning
Specialization in teams only increases with time
People are different and not everybody is so rational to
apply relative complexity estimates
It is easy to hide personal ineffectiveness behind SP, so
less focus on personal responsibility
Developers have different focus factor
Some work hard and some just relax
Why SP doesn’t work for Spring Planning
Specialization in teams only increases with time
People are different and not everybody is so rational to
apply relative complexity estimates
It is easy to hide personal ineffectiveness behind SP, so
less focus on personal responsibility
It is hard to understand what went wrong and find
failure reasons to fix them
Help Dasha to find out why Sprint failed
General burndown may lie or be useless
Specialization issues are invisible
Let’s think about ideas hours instead…
Ideal means you have all needed resources, know
everything, don’t have interruptions and feel good
Another popular name is “productive hours”
Easy to explain to everybody, even outside of the team
Have focus on personal responsibility/commitment
Force people to find wastes and work on them
Not so easy to start with, some preparation required
Hours are always personal with all side effects
Super power with spreadsheets
#1. Implement team capacity calculator
Detailed instructions
Define and agree focus factor for each team member,
taking into account all aspects
Specify seniority factor to balance hours [OPTIONAL]
Use main competence of team members for grouping
Fill team individual Sprint calendars (1 – full day, 0.5 –
half day, 0.25 – couple of hours)
Mark team events and time consuming meetings
Calculate total capacity by competence
#2. Discuss backlog and estimate in hours
Detailed instructions
Full team discusses each proposed backlog item
Estimation is done by each competence group
It is important to have agreement regarding seniority
factor to balance hours
Fill estimates in the Sprint Backlog table
When there are no more capacity in competence group
discuss how team is going to handle this situation
Distribute remaining capacity on other work types
Generate tasks automatically in TMS by the table
Planning Poker is still actual
#3. To understand
how much work
left you need to
track time
Rise and fall of Story Points. Capacity based planning from the trenches.
Detailed instructions
Due dates may be used based on estimates
Personal responsibility and risk management works
much better
Instead of tracking spent hours team members could
override remaining hours on Daily Scrum
Team notifications may be implemented for better
transparency
Technical retrospectives may be scheduled to discuss
and tune estimates
Team collaboration is now math-driven
Better transparency and more focus guaranteed
Continuous waste analysis could be implemented
Summary and take aways
Story Points work well for project estimates and
release planning
Team diversity breaks ideal world
Sprint differs in many aspects
Ideal hours focus on wastes
Hours bring responsibility and commitment
Capacity calculator in needed for the team
Stories are split on tasks and then estimated in hours
Enjoy great tool for continuous improvements!
@xpinjection
https://xpinjection.com
https://t.me/xpinjection_channel
1 of 44

More Related Content

Similar to Rise and fall of Story Points. Capacity based planning from the trenches.(20)

Planning to Stick to the Plan.pdfPlanning to Stick to the Plan.pdf
Planning to Stick to the Plan.pdf
UpraiseSuccess16 views
1.How to Prepare FINAL!1.How to Prepare FINAL!
1.How to Prepare FINAL!
Timothy Dietrich164 views
Agile estimates -  Insights about the basicAgile estimates -  Insights about the basic
Agile estimates - Insights about the basic
Diogo S. Del Gaudio127 views
:: Agile Scrum Methodology :::: Agile Scrum Methodology ::
:: Agile Scrum Methodology ::
Zubaida Tasmeen Eliza 🇧🇩123 views
Scrum Master 101Scrum Master 101
Scrum Master 101
David Wallace440 views
Facilitate a Timeline FuturespectiveFacilitate a Timeline Futurespective
Facilitate a Timeline Futurespective
Jolly Rajan1.7K views
Agile camp2016 agile101Agile camp2016 agile101
Agile camp2016 agile101
Erin Bolk561 views
Group Project II                                                  .docxGroup Project II                                                  .docx
Group Project II .docx
benjaminjames216813 views
Agile Project ManagementAgile Project Management
Agile Project Management
Sinaporn (Pam) Suebvisai1.6K views
ErpErp
Erp
Palash Biswas201 views
My understanding about ScrumMy understanding about Scrum
My understanding about Scrum
Jason Guo (PMP)76 views
Backlog Refinement 101 & 202Backlog Refinement 101 & 202
Backlog Refinement 101 & 202
David Hanson623 views
Accelerator Workshop "Before"Accelerator Workshop "Before"
Accelerator Workshop "Before"
Yvonne Shek2.9K views
Agile ScrumAgile Scrum
Agile Scrum
Hesham Shabana110 views

More from Mikalai Alimenkou(20)

Hexagonal architecture with Spring BootHexagonal architecture with Spring Boot
Hexagonal architecture with Spring Boot
Mikalai Alimenkou2.2K views
Hexagonal architecture with Spring BootHexagonal architecture with Spring Boot
Hexagonal architecture with Spring Boot
Mikalai Alimenkou8.8K views
Bro, manage test data like a pro!Bro, manage test data like a pro!
Bro, manage test data like a pro!
Mikalai Alimenkou968 views
Developer + tester = quality++Developer + tester = quality++
Developer + tester = quality++
Mikalai Alimenkou4K views

Rise and fall of Story Points. Capacity based planning from the trenches.

  • 1. Rise and fall of story points. Capacity-based planning from the trenches. Mikalai Alimenkou @xpinjection https://t.me/xpinjection_channel https://xpinjection.com
  • 4. Disclaimer This talk is based on personal experience
  • 5. My expectations 10 years ago for 2020 Agile unicorn
  • 6. Reality in many companies/teams Agile unicorn
  • 8. Talk “Agile anti-patterns: 10 years later” https://www.youtube.com/watch?v=XTsf7quT2nM
  • 9. #2. Story Points for Sprint Planning
  • 10. WE ALL HAVE USED IT FOR YEARS!
  • 12. Release planning could rely on SPs
  • 13. Because this is just prediction game
  • 14. The most serious issue in our industry
  • 16. Sprint Planning differs in many aspects Requirements are READY for development, so no uncertainty presents If something has risk, then it is better to extract spike from it and take for discovery with fixed timebox Team knows HOW to implement requirements, so it is able to split them into development tasks Team structure, skills, experience and available resources are 99% stable for single iteration
  • 18. Why SP doesn’t work for Spring Planning Specialization in teams only increases now
  • 19. SP may work for “full-full-stack” teams
  • 20. Confusing and dangerous for mixed team
  • 22. Why SP doesn’t work for Spring Planning Specialization in teams only increases with time People are different and not everybody is so rational to apply relative complexity estimates
  • 24. Rational VS Irrational team members
  • 25. Why SP doesn’t work for Spring Planning Specialization in teams only increases with time People are different and not everybody is so rational to apply relative complexity estimates It is easy to hide personal ineffectiveness behind SP, so less focus on personal responsibility
  • 27. Some work hard and some just relax
  • 28. Why SP doesn’t work for Spring Planning Specialization in teams only increases with time People are different and not everybody is so rational to apply relative complexity estimates It is easy to hide personal ineffectiveness behind SP, so less focus on personal responsibility It is hard to understand what went wrong and find failure reasons to fix them
  • 29. Help Dasha to find out why Sprint failed
  • 30. General burndown may lie or be useless
  • 32. Let’s think about ideas hours instead… Ideal means you have all needed resources, know everything, don’t have interruptions and feel good Another popular name is “productive hours” Easy to explain to everybody, even outside of the team Have focus on personal responsibility/commitment Force people to find wastes and work on them Not so easy to start with, some preparation required Hours are always personal with all side effects
  • 33. Super power with spreadsheets
  • 34. #1. Implement team capacity calculator
  • 35. Detailed instructions Define and agree focus factor for each team member, taking into account all aspects Specify seniority factor to balance hours [OPTIONAL] Use main competence of team members for grouping Fill team individual Sprint calendars (1 – full day, 0.5 – half day, 0.25 – couple of hours) Mark team events and time consuming meetings Calculate total capacity by competence
  • 36. #2. Discuss backlog and estimate in hours
  • 37. Detailed instructions Full team discusses each proposed backlog item Estimation is done by each competence group It is important to have agreement regarding seniority factor to balance hours Fill estimates in the Sprint Backlog table When there are no more capacity in competence group discuss how team is going to handle this situation Distribute remaining capacity on other work types Generate tasks automatically in TMS by the table
  • 38. Planning Poker is still actual
  • 39. #3. To understand how much work left you need to track time
  • 41. Detailed instructions Due dates may be used based on estimates Personal responsibility and risk management works much better Instead of tracking spent hours team members could override remaining hours on Daily Scrum Team notifications may be implemented for better transparency Technical retrospectives may be scheduled to discuss and tune estimates
  • 42. Team collaboration is now math-driven Better transparency and more focus guaranteed Continuous waste analysis could be implemented
  • 43. Summary and take aways Story Points work well for project estimates and release planning Team diversity breaks ideal world Sprint differs in many aspects Ideal hours focus on wastes Hours bring responsibility and commitment Capacity calculator in needed for the team Stories are split on tasks and then estimated in hours Enjoy great tool for continuous improvements!