Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

Люди в мире Agile используют Story Points - для Agile коучей и тренеров это самый простой способ объяснить, как следует проводить оценку и планирование в «новом мире». Но тогда эта простая концепция нарушает реальные практические кейсы. В настоящее время команды состоят из очень специализированных людей, работающих над бэкендом, фронтэндом, тестировании, инфраструктуре и прочим. Для них почти невозможно иметь общий уровень сложности. Это только одна из проблем, которые мы собираемся осветить в этом докладе.

Чтобы оставаться конструктивным, а не просто старомодным парнем из XP, Николай поделится своим опытом с более точной и прагматичной техникой оценки/планирования - планированием на основе возможностей.

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

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

  1. 1. Rise and fall of story points. Capacity-based planning from the trenches. Mikalai Alimenkou @xpinjection https://t.me/xpinjection_channel https://xpinjection.com
  2. 2. Telegram channel https://t.me/xpinjection_channel
  3. 3. Disclaimer This talk is based on personal experience
  4. 4. My expectations 10 years ago for 2020 Agile unicorn
  5. 5. Reality in many companies/teams Agile unicorn
  6. 6. Sometimes situation is even worse
  7. 7. Talk “Agile anti-patterns: 10 years later” https://www.youtube.com/watch?v=XTsf7quT2nM
  8. 8. #2. Story Points for Sprint Planning
  9. 9. WE ALL HAVE USED IT FOR YEARS!
  10. 10. Release planning could rely on SPs
  11. 11. Because this is just prediction game
  12. 12. The most serious issue in our industry
  13. 13. Capacity-driven planning https://www.mountaingoatsoftware.com/blog/why-i-dont-use-story-points-for- sprint-planning Mike Cohn
  14. 14. 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
  15. 15. Why SP doesn’t work for Spring Planning Specialization in teams only increases now
  16. 16. SP may work for “full-full-stack” teams
  17. 17. Confusing and dangerous for mixed team
  18. 18. 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
  19. 19. Frequent situations behind Story Points
  20. 20. Rational VS Irrational team members
  21. 21. 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
  22. 22. Developers have different focus factor
  23. 23. Some work hard and some just relax
  24. 24. 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
  25. 25. Help Dasha to find out why Sprint failed
  26. 26. General burndown may lie or be useless
  27. 27. Specialization issues are invisible
  28. 28. 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
  29. 29. Super power with spreadsheets
  30. 30. #1. Implement team capacity calculator
  31. 31. 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
  32. 32. #2. Discuss backlog and estimate in hours
  33. 33. 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
  34. 34. Planning Poker is still actual
  35. 35. #3. To understand how much work left you need to track time
  36. 36. 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
  37. 37. Team collaboration is now math-driven Better transparency and more focus guaranteed Continuous waste analysis could be implemented
  38. 38. 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!
  39. 39. @xpinjection https://xpinjection.com https://t.me/xpinjection_channel

×