story points v2
•Als PPTX, PDF herunterladen•
0 gefällt mir•1,361 views
User story points are used for estimation because software projects are complex with many factors that make hour-based estimation inaccurate. Story points use a relative scale where user stories are assigned points based on their size compared to baseline reference stories. This allows for more accurate planning across sprints and continuous improvement of estimates as a team's velocity is tracked over time. The key aspects are regularly practicing estimation as a skill, having a shared understanding of baseline stories, and focusing comparisons only on effort required to complete stories.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie story points v2
Ähnlich wie story points v2 (20)
story points v2
- 3. Why story points NOT hours?
- 4. From the latest Standish group survey 68% Fail to meet original estimates
- 5. We are not good at estimation Acceptable number Project is too big Deception: best/worst case And also…
- 6. Software projects are complex
- 9. Software projects are complex maintainability testability scalability security changing requirements Hours estimation is not good enough Why story points?
- 11. 11
- 12. Less variation Stable reference stories
- 13. 13
- 14. 14
- 15. 15 70 minutes 30 minutes VS Office to People square 140 minutes 60 minutes Office to the bund Difference 40 minutes 80 minutes
- 19. Start using story point?
- 21. 2 baseline user stories “2” & “5”
- 22. Compare size to baseline stories From start to “Done”
- 23. Improve estimation Inspect & Adaptive
- 24. Key take away • Estimation is a skill. It requires practice • Baseline stories need to be understood & accepted by all team members • Baseline stories should not changed from sprint to sprint till you (the team) are too fast • Make comparison based on effort, not complexity, not business value, etc. 1 thing in a time 24
- 26. Try: decide 2 baseline user stories with your team 26
- 27. Thank you! 27
Hinweis der Redaktion
- Cost, when, planning, how many feature we can do Estimation is an activity of the right brain: (the right brain being known for emotions and imagination, and ideas about the future and the unknown)
- About The Standish Group International, Inc. Since 1985 The Standish Group, the leader in spotting future trends, has been helping end users and vendors of technology solutions prepare for the future. The Standish Group delivers fast, consistent and reliable IT advice built on a solid foundation of primary research. For further information on project studies and other trends, visit our website at: www.standishgroup.com.
- Not that developers are being intentionally deceptive, but we have a tendency to estimate the best case or what we think is the worst case. No matter how honest a developer tries to be in giving an hours estimate, there is always a tendency for the thought to lodge in the back of his mind that they have to give a number of hours that is acceptable rather than the number of hours he actually thinks the work is going to take. In addition, especially in the beginning of the project or in the estimation process, the tasks are so large that most just throw a rock in the general direction and call it good because there's no way they can get enough detail to respond with an estimate in time to be considered unless they do. Take longer time to explain what we are not good in hour estimation http://checkedexception.blogspot.com/2011/08/why-story-points-are-more-accurate.html
- Example: how long time it will take to go home? I can travel up and down the same street for twenty years, and things would be different every time. There is no way to fully understand and know what happens around me on the road when I drive, how other drivers operate their vehicles, and how the people in the streets interact. I can make guesses, and I can gain experience in predicting outcomes. But I will never know for sure. http://www.noop.nl/2008/08/simple-vs-complicated-vs-complex-vs-chaotic.html
- My car key is simple. My car is complicated. Car traffic is complex. Car traffic in Hanoi is chaotic. The Cynefin (pronounced /ˈkʌnɨvɪn/) framework in which the relationship between cause and effect http://en.wikipedia.org/wiki/Cynefin
- Writing a quality software is a very complex process. It must not only meet all the functional requirements, but also should address non-functional requirements like robustness, responsiveness, maintainability, testability, scalability, security, supportability, monitorability, and disaster recoverability to satisfy not only the immediate business needs, but also flexible enough to adapt to growing and changing business needs. Anyone who has been in the software industry for a while will vouch for how quickly the business priorities can change. They also strongly understand that the following aspects need to be properly thought through from the beginning of a software project.
- First, estimate related number is more accurate than estimate the absolute number
- How long it will take to get to Grand cinema How long it will take to get to People square
- Secondly, Not only about accuracy there is a huge variation in effort needed to complete a task depending on who is doing it. This factor remains whether you do story points or whatever other estimation technique. http://labs.openviewpartners.com/scrum-why-story-points-are-better-than-hours/
- Thirdly, relating hours to story points causes a huge impediment for the team. If the team in generating continuous process improvement, the hours per story point will be continually decreasing. Assuming a number of hours per story point makes it impossible for the team to show they have improved and fixes in their mind that there is a reasonable number of hours per story point. http://scrum.jeffsutherland.com/2010/04/story-points-why-are-they-better-than.html
- Fourthly, The number of story points the team can deliver per unit of calendar time
- Business value? Complexity?
- Every one, solid understanding on what need to do for the baseline user stories from scratch to “done”