[HCM Scrum Breakfast] Agile estimation - Story points
•
7 gostaram•2,061 visualizações
This document provides information about agile estimation techniques, including story points and planning poker. It discusses how story points are used to provide relative estimates of complexity rather than time estimates. Planning poker is described as a consensus-based technique where a team privately selects story point cards before discussing to reach agreement. The document also covers insights around how additional details don't necessarily lead to better estimates and how past sprint performance can inform long-term planning estimates. Common questions about estimation techniques are addressed.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a [HCM Scrum Breakfast] Agile estimation - Story points
Semelhante a [HCM Scrum Breakfast] Agile estimation - Story points (20)
Mais de Scrum Breakfast Vietnam
Mais de Scrum Breakfast Vietnam (20)
Último
Último (20)
[HCM Scrum Breakfast] Agile estimation - Story points
- 1. Agile Estimation Story Points Pedro Gonzalez
- 2. Imagine that... You get sick of Software development as a career And you decide is to go into the restaurant business
- 3. How would you estimate this? Your first job is to move all these glasses to the tables outside in the garden 20 meters
- 4. Story points Game Some insights about estimations Planning poker Long-term planning FAQ Agenda
- 5. Story Points
- 6. What’s a story point? “An estimate of relative complexity of a user story” It is a unitless number, but still a useful number Story Points
- 7. Most commonly used estimating unit in Scrum teams Factors involved Volume: How much is there? Complexity: How hard it is? Uncertainty: What’s NOT known? What’s known? Story Points
- 8. 1. Forces the use of relative estimating There are studies that show that we’re better at this (1) 2. Focuses on estimating size, not duration We can derive duration empirically 3. Unlike time estimates, it puts estimates in units that we can add together A 10-point user story is expected to take twice as long as a 5-points user 3 Key Advantages (1) https://www.google.com.vn/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0ahUKEwjVn6GawK7OAhUFk5QKHfGXAwoQFggpMAI&url=https%3A%2F%2Fwww.simula.no%2Ffile%2Fsim ulasimula814pdf%2Fdownload&usg=AFQjCNHkTpakk2JSFS--CGpwiqn6hoSdBw&sig2=x-5y_uQlXbl1LSzZCCvq0g&bvm=bv.129391328,d.dGo
- 9. 3 Key Advantages Who is going to do it faster?
- 10. Game5 minutes to form 5-8 people teams
- 11. Europe
- 13. Spain: 505,990 km2 Portugal: 92,212 km2 Actual Areas Spain: 5x Portugal: 1x
- 15. 1. Group A Given project spec 2. Group B Given the same spec but with estimation irrelevant details List of users List of passwords Some Insights about estimations 1. 20 hours 2. 39 hours
- 16. 1. Group A Given a 1-page project spec 2. Group B Given a 7-pages project spec Double line space Margins Some Insights about estimations 1. 117 hours 2. 173 hours
- 17. 1. Group A Given requirements R1-R4 2. Group B Given requirements R1-R5 3. Group C Some Insights about estimations 1. 4 hours 2. 4 hours 3. 8 hours
- 18. 1. Group A Given project spec 2. Group B Given project spec Customer thinks it’ll take 500 hours Some Insights about estimations 1. 456 hours 2. 555 hours 3. 96 hours
- 19. More information will not always provide better estimations Estimations get influenced very easily by external factors Some Insights about estimations
- 20. Planning Poker
- 21. Planning Poker Estimator Round 1 Round 2 Minh 3 5 Tam 8 5 Thang 2 5 Truc 5 8 Phuong 3 5
- 22. 1. PO explains the User Story 2. Q&A (3 mins) 3. Each team member selects card and shows 4. High and low explain and discuss If more than 2/3 minutes —> Revote Converges after 2-3 rounds Planning Poker
- 23. Planning Poker Why fibonacci series?
- 24. Planning Poker Why fibonacci series? 1 2 3 5
- 25. Planning Poker Why fibonacci series? 1 2 3 5
- 26. Planning Poker Wait, it’s not exactly fibonacci
- 27. People doing the work, estimate the work Estimators are required to justify estimates Estimates are constrained to a set of values So we don’t waste time in meaningless arguments Group discussions lead to better estimates Emphasizes relative instead of absolute estimates Planning Poker - Why does it work?
- 29. Long-term Planning Average of 3 worst sprints 27.3 Average of 3 best sprints 38.3
- 30. Long-term Planning y=27.3xy=38.3x User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story Less priority
- 31. Long-term Planning y=27.3xy=38.3x User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story User story Less priority
- 33. FAQ What if there is no Front-End work in the story?
- 34. FAQ What if my team is remote? https://www.planningpoker.com/
- 35. FAQ What if the story is not clear yet? What part is missing? Play with the uncertainty part Assume the worst scenario
- 36. FAQ What if there are dependencies? Can you join dependent stories into a bigger story? Can you create one story for the common work and STILL add value? Do 2 estimations for the dependent stories: 5 if done first 2 if done later
- 37. FAQ What about teams new to Scrum? http://theagilepirate.net/archives/109
- 38. FAQ How to prevent estimate inflation? 1 2 5 3
- 39. FAQ How to prevent estimate inflation? 1 3 5 2
- 41. Agile Estimation, Mike Cohn - https://www.youtube.com/watch?v=fb9Rzyi8b90 Agile Product Ownership in a Nutshell - https://www.youtube.com/watch?v=502ILHjX9EE https://www.simula.no/publications References
Notas do Editor
- Zoom x3 My name is Pedro and I am currently Scrum Master at TINYpulse Been working with 3 teams so far One of the most difficult part is to understand points
- You don´t like your manager We have the deadlines - it´s stressing From SW dev to FOOD & Beverages You start as a waiter
- Your boss comes “I need you to tell me how long you need to move all these glasses Can you come back in 10 mins?” You need a tool → TRAY Have an estimation of how many trays is that After 30 minutes, see how many trips you have you done → Calculation Why did we do that this way? → We inspect first, and adapt
- What’s a story point? “An estimate of relative complexity of a user story”
- It compares how much you thought you can finish VS how much you actually finish Estimate is not a commitment
- Volume → High intensity tasks (like localization) Complexity → Number of cases, possible interactions, many user profiles Uncertainty → We don’t need all details Best estimators are QA → Because they focus on complexity of the story, and not SPECIFIC TASKS
- Human being tends to be optimistic Just like the trips for the waiter before Why can’t we add hours estimates? Elaborate Because it makes people think that it will be done in X weeks It doesn’t factor in side effects (like events, bank holidays, etc.) 80 hours → 2 weeks Explain the example of 2 runners making a 5 kms trial In 10 mins / 15 mins
- The important point is the AGREEMENT
- Split into groups - 3 minutes
- 2 Rounds How many times is Portugal contained in Spain? KM2 RELATIVE
- Who got around +- 20,000 Who got 5?
- Talk about Simula company Norwegian company
- Joke about the estimation by kilos from spec book
- B - Maybe no work involved C - Buffer for later requirements
- And the funniest thing is that they were asked if the customer estimation influenced them
- That’s how it works normally
- When the team is discussing a LONG TIME , getting LARGE and LARGE Stop and ask, “What’s the simplest version that can possibly work?” Capture that simple version as its own story Break out all the variations and complexities into their own stories.
- Mike Conh wanted to challenge their teams about ways of estimations They started using just numbers They complained about long discussions 14 or 15??? One came up with the idea that they don’t use those numbers Long discussions
- Then the numbers would be considered like buckets → Implicit buffer
- But the buffers were too big specially for big numbers A bucket of 13 kilos can hold 14-15 kilos of sand
- Because a PO asked why a 21 specifically → You must be into something! Because fibonacci! → (fibo what?)
- For more EXPERIENCED teams
- As a PO, you can get 2 questions When will I get THIS done?
- What will be done by the end of sprint 7?
- If you get these stories too frequently, you should ask if your team is really cross-functional Talk about mobile guys in the team
- PO can’t just go and say “Make this part better” But there are other cases like design tweaks that you can still assume the worst
- McDonalds has burguer for 5$, and chips for 3$ However the Combo is 7$
- Present stories Let the team sort them by the swimlames
- Story triangulation
- I hope this can improve your teams doing estimations Talk about all my learnings