Managing Products with Agility [P1]: Managing Products with Agility/Forecasting and Release Planning - Myth 9: story points are required in Scrum Flashcards
Why does the myth exist? (story points are required in Scrum)
Purpose of estimation in Scrum and Story Points is misunderstood
What are story points?
- Used to estimate effort with relative estimates instead of time-based estimates (hours, days etc)
- Done using simplified Fibonacci sequence
- Numbers only have meaning in relation to other items
- based on what has already happened (e.g. teams velocity) and not on what wehopewill happen
What is the simplified version of Fibonacci sequenced used for story point?
0, 1, 2, 3, 5, 8, 13, 20 etc
What does the Scrum Guide say on estimation?
- “work may be of varying size, or estimated effort”?
- does not prescribe how estimation should be done
- tells us to use an approach that respects the complexity of software development and to not let estimation replace the importance of empiricism itself
- i.e. Scrum Guide busts the myth
What is the purpose of estimation in Scrum?
- give Dev Team a rough sense of the amount of work they can pull into a Sprint
- Scrum ackowledges that what will happen in the (near) future is largely unknown
- “Only what has already happened may be used for forward-looking decision-making”
What does the team commit to in terms of work? Sprint Goal? All work within the Sprint?
- commits to achieving the Sprint Goal
- do not commit to completing all this work within the Sprint
[IMPORTANT!!]
What are 4 key insights for estimates in Scrum?
- 1) Accurate estimates are impossible
- 2) An estimate can’t be a guarantee
- 3) estimation is a form of waste
- 4) estimatesthemselves are the result of a necessary conversation within theDevelopment Teamto arrive at a shared understanding
What is the problem with time-based estimates - hours, ideal days?
- uphold the illusion of accuracy and predictability, and are often interpreted as such
- their illusion of accuracy often drives teams into ‘analysis paralysis’, where all details need to be discussed in-depth in order to arrive at a detailed estimate
Benefit of using relative estimation
avoid all pretense of detail and accuracy - provide guide on the amount of work the team may be able to complete within a sprint
Can teams still estimate in hours or ideal days?
Yes, but need to be aware of disadvantages
Alternatives to estimating individual items
- 1) use the number of items per Sprintas a guide to select a doable amount of work for a Sprint
- 2) Usesize bucketsas a guide, where the Development Team classifies items in terms of size (e.g. large, medium, small)
- 3) use the combinedgut feelingof the Development Team to determine if enough work was selected
- For each (1) and (2), use history/velocity
Why do we feel that estimation is useful?
- helps to focus the conversation within a Development Team on what is needed for a particular item
- Triggers questions that promote discussions to create shared understanding
Should the entire team be present for estimations?
- Yes - shared understanding in the team
- Everyone’s knowledge used to identify issues or oversights
What is an idea to communicate the growing uncertainty of time based estimations?
- create time buckets with increasing intervals (e.g. 1 hour, 2–3 hours, 3–5 hours, 5–8 hours)
- communicates more clearly the growing uncertainty as a result of a higher estimate
Is “i don’t know” a valid answer to questions like “how much will it cost” or “how long will it take”
Yes
