Rise and fall of Story Points. Capacity based planning from the trenches.
•
4 likes•2,317 views
Люди в мире Agile используют Story Points - для Agile коучей и тренеров это самый простой способ объяснить, как следует проводить оценку и планирование в «новом мире». Но тогда эта простая концепция нарушает реальные практические кейсы. В настоящее время команды состоят из очень специализированных людей, работающих над бэкендом, фронтэндом, тестировании, инфраструктуре и прочим. Для них почти невозможно иметь общий уровень сложности. Это только одна из проблем, которые мы собираемся осветить в этом докладе. Чтобы оставаться конструктивным, а не просто старомодным парнем из XP, Николай поделится своим опытом с более точной и прагматичной техникой оценки/планирования - планированием на основе возможностей.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Rise and fall of Story Points. Capacity based planning from the trenches.
Similar to Rise and fall of Story Points. Capacity based planning from the trenches. (20)
More from Mikalai Alimenkou
More from Mikalai Alimenkou (20)
Recently uploaded
Recently uploaded (20)
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
- 7. Sometimes situation is even worse
- 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
- 23. Frequent situations behind Story Points
- 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
- 26. Developers have different focus factor
- 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
- 31. Specialization issues are invisible
- 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!