The Subtle Art of Getting Close Enough in Story Estimation
NOTE: While reading about story point estimation, I stumbled upon an intriguing fact. Contrary to my belief that “Story points are part of scrum” when I went through the scrum guide, it was nowhere to be found.
For business, when our customers express interest in something, we must meticulously plan it and analyze the ROI, all while deftly managing their expectations. Estimations help the stakeholders to make informed decisions about the worthiness of a venture and enable us to chart a course toward timely delivery.
Typically, the stakeholders define the business value and the dev team defines the efforts. This helps make informed decisions about what’s next and come up with a delivery date.
Estimations have long been a subject of intense debate within organizations. I feel our collective struggles lay in “our assumption that estimates == promises”. This may come from our fear to say that “I don’t fully know” or going with uncertainty to BUs coupled with the misconception that estimates are a one-time affair and pushing to go full-on plan-driven rather than value driven. I see not re-estimating as a missed opportunity to continually refine our vague high-level estimates and put the newfound knowledge back in the system.
Why Estimate?
The key motivation for story points is to estimate the work so we can know what can be done each time. Since time is an easy measurement, hours were commonly used for estimation because we can quantify it easily and come up with costs.
However even after the best try it’s hard to estimate the non-mechanical activities like development as the outcome depends on intangible factors like information, complexity, the expertise of the dev team, and other dynamic factors.
Given the difficulty of pinning down precise estimates, one might question the necessity of estimation altogether, favoring a factory worker model of development and delivery. However, for products with a roadmap, where foresight and strategic planning are crucial, we must embrace estimations as a means of understanding the possibilities and charting our path forward.
We should understand that estimations only provide “POSSIBILITIES”. If we have this understanding clear then any unit can be used for estimation (‘hours’, ‘story points’, or ‘T-shirt size’).
Typically in such scenarios, the fundamentals questions from stakeholders are:
1. When will it be done?
2. How much will it cost?
As companies need some forecasting strategy to enable them to understand the needs of their audience and fulfill them with precision. Although it may be considered a rhetorical question, if it were appropriate, I would ask:
Dear Client, would you rather
1. Embrace uncertainty and allow us to build the most valuable thing at that time. OR
2. opt for upfront knowledge of timelines, even though it might be an illusion?
What is Story Point?
Story points are a sequential series of sizes to estimate any unit of work. They are an imprecise forecast of a team’s capacity/velocity, helping to develop shared understanding, and useful in negotiating task priority.
Though this definition is simple, it’s important to understand:
What Story Points are NOT?
- Estimate of time.
- The measure of exact time spent.
- Time tracking
- Exact end dates
- It can’t be used to compare with other teams as it’s relative and unique to a team.
We can use tools like planning poker or the Fibonacci model to estimate. The intent is to foster an open dialogue to gain a shared understanding of the work relative to all user stories in the product backlog.
The dominance of Story points
Long gone are the days when the time was considered to be the only supreme standard unit of planning because the problem lies in the fact that
“ Your hour is not the same as my hour”.
Two Devs may give different hour estimates for the same task while some gaps may be understandable due to skill, specification, or understanding but if the Devs were to rate the amount of effort required in comparison to other backlog items we are far more likely to end up with consensus.
The practical challenges associated with utilizing time can be elucidated by considering two distinct concepts: ideal time and elapsed time. The lack of clarity between these concepts often contributes to the unreliability of time estimates. Ideal time operates on the assumption that…
- The individual performing the task possesses all the necessary knowledge and resources right from the beginning of the job.
- The developer is solely dedicated to working on that specific task until its completion, without any other simultaneous commitments.
- There are no interruptions or obstacles that could hinder the progress of the work.
People usually understand that estimates are just estimates. But as soon as we attach it with ‘Hours’, it kind of becomes a definitive measure, it builds up expectations of accuracy. But when these expectations go inevitably unmet, it causes conflicts, breaks trust, and causes more damage to teams.
Though the hour-based estimates can easily help calculate costs, we ignore the major drawbacks of this approach. It doesn’t focus on efficiency; it ignores the efforts spent and just weighs in the time spent.
Companies developed their methods of estimating work through this system, such as the Fibonacci method, the t-shirt sizing method, and the bucket system, through dot voting or affinity mapping.
The Confusion and Challenges
Story points are nebulous and arbitrary value and it doesn’t give an exact measure of time thus one of the initial challenges with story pointing is even Scrum teams cannot make predictions on how many story points can be completed in a sprint(velocity) until the few strings are over.
Another challenge is that” It is not easy to have a common understanding that estimation is all about possibilities and also to have a common understanding of estimates with people of different skill sets, background and stakes may vary.”
Also, to build the perspective in coaching story points is to recognize that they represent size or volume is difficult. we need to understand “velocity is a result, not a desire”. Scrum practitioners should prioritize Outcomes over output and value over volume.
Another factor to consider is that the story points may change based on changes in the environment, team members, their moods, complexity, and so on. But research shows that group estimates are much more accurate than individual estimates.
Estimating using relative numbers.
We can use the reference story and triangulation techniques. At the start, the team should be presented with sample stories that could be assigned the first few numbers of Fibonacci. Since estimations are relative first goal should be able to identify the smallest story and assign 1SP to it and relating to this we can estimate future stories.
In the Triangulation technique, we not only check the reference number but also the other two around it. If you were to assign 2SP you need to also find stories which you would rate 1SP and 3SP and see if it lies between them.
Some teams use the Golden story in which the first story for the product is estimated and this is used as a point of reference throughout the lifecycle of the product. Also, we should consider the below 3 factors while relative estimation:
- Complexity
- Effort
- Uncertainty
Avoid…
- Taking about days
Some more cautious stakeholders convert story points into hours. Each one has their method but the most common is benchmarking. The problem with this is it accounts for the ideal time and not elapsed/real-time disruptions, delays, etc.
2. Management shouldn’t be manipulating with team’s point.
By empowering the teams to take ownership of their estimates, we foster a culture of trust, collaboration, and accurate forecasting, setting the way for successful project outcomes.
3. Spending too much time on process intricacies.
Estimation Frameworks
Let’s address a minor setback: discussing the methodologies for various estimation techniques in detail might make this overly long and potentially less captivating. I’ve discovered some captivating links, which you can explore further.
Planning Poker estimation technique is a consensus-based approach used in agile project management to estimate the effort or complexity of tasks. Team members privately select a card representing their estimate, which is then revealed simultaneously. The technique encourages unbiased input and facilitates discussion to reach a collective estimate for each task.
NOTE: In this, there can be two additional cards, a question mark for if someone doesn’t understand enough to give estimates, and a coffee cup for “Team, I need to take a break”.
The employs t-shirt sizes (XS, S, M, L, XL) as estimation categories, representing the sizes of stories. Participants assign items to the appropriate categories, which can then be translated into numerical estimates. Consensus is reached through discussions and, if needed, voting, ensuring agreement within the entire team.
Fibonacci story estimation is an intriguing approach where the Fibonacci sequence (0, 1, 1, 2, 3, 5, 8, and so on) is used to assign relative sizes or complexity to user stories in agile project management. By leveraging the sequence’s increasing values, teams can effectively prioritize and estimate tasks, embracing a flexible and collaborative estimation process.
This technique is quite similar to Planning Poker. Estimation is done by placing the items in buckets, each bucket representing an estimate, in several smaller groups.
Conclusion
Let’s be transparent here (which seems fitting, don’t you think?). Relative estimation isn’t a universal solution but rather an additional tool in your team’s estimation toolkit. To effectively perform relative estimation, the team must still possess a solid grasp of the story, and planning poker serves as an excellent platform for facilitating those discussions. Certain stories may benefit from planning poker, while others can be more easily estimated relatively. It’s hard to do planning poker with remote teams but there are many online tools to aid this.
The choice of estimation technique is in your hands. Remember, these techniques are flexible and can be adapted or modified each sprint, ensuring a seamless estimation process for everyone involved. Feel free to explore and choose what’s best for your project.
So, Dear Reader, May you embark on your estimative odyssey with confidence!
Happy Learning 🙌
