-
|
- Agile |
- Estimation |
Story Points: Whats the point?
Story Points are awesome... Except for the 99% of the time they are point-less.
Let me start by saying that I do believe that Story Points are if not one of the best ways to provide high-level project estimates. However, in my experience the usage of Story Points and their underlying benefits are greatly misunderstood, which affects their usefulness and reputation.
1. Story Points are for HIGH-level project estimates.
In the past, during the waterfall era, projects were analysed, estimated, and planned upfront using time-based estimates and presented using Gantt charts. The inevitable inaccuracy of estimates often led to adjusting the project plan, requiring extra work.
One solution to this is the concept of Story Points, which is an arbitrary measure of how much effort each task would require. It allows you to compare various tasks and determine if more, less, or the same amount of effort is required. By summing up the total number of outstanding Story Points and dividing it by the number of points the team is working through each week (their velocity), you can get a rough idea of how many weeks are left to complete the remaining work.
The beauty of this abstraction, is that as the teams velocity fluctuates, you can easily adjust the projected project timeline.
Where does this go wrong
The strength of this approach lies in the abstraction of time from the original estimates. However, once teams start tying the value of the arbitrary point system to time by focusing on their velocity, they end up back at the beginning. No longer are they focusing on the relative effort of a task compared to others; they are now simply estimating how long a task will take.
2. What do Story Points measure
By definition, Story Points are a relative measure of “effort." This encompasses all aspects of getting a task into production, including analysis, development, QAT, UAT, and release into production. Effort includes, but is not limited to, considering the task complexity and its impact across the Dev-Test-Release cycle, the repeatability of the task, and challenges with stakeholder management and communications.
Where does this go wrong
One of the challenges people have with Story Points is that they are an arbitrary number, and humans struggle with ambiguity and arbitrariness. They look to connect the numbers with something more tangible, such as time. As discussed above, this is the root of why Story Points were invented, and bringing them back to time puts us back to our original problem. Another issue is that Story Points are commonly referred to as a measure of “Complexity,” which disregards many aspects of both a task and the overall effort required to complete the task into production.
3. Story Points are team-specific
Each team has a unique set of challenges, tasks, members, and level of team maturity. Therefore, each team estimates its tasks in a unique way. For example, a social media team may allocate a 1-point value to a simple social media post, while larger campaigns may range from 3 times the effort of a post up to about 8 times, i.e., 3 points up to 8 points. On the other hand, a data team may allocate a 1-point value to their simplest task of generating an analytics report, while analysing months' worth of posts and campaigns may require 13 points, with tasks varying in effort in between.
Where does this go wrong
Lets assume that Team A can produce 4 posts a day (or 20 posts a week), and Team B can produce 1 report a day (5 per week).
Comparing theese teams indicates that Team A (20 pts) is 4 times as productive as Team B (5 pts), when in reality here were are comparing Apples to Oranges, each team is unique, their tasks are unique, and so are their challenges. Based on points alone, we cannot determine which team is more “productive."
A common solution to this issue is to standardise the point values. 1 point = 1 day, therefore each post for Team A, is 0.25, and each report for Team B is 1 point. However, as discussed earlier, we have now removed the focus from being a relative estimate and might as well use a time-based estimate.
4. Story Points are not a reliable measure of Productivity
Let’s for a moment assume that a team can estimate tasks with 100% accuracy, and the team is 100% dedicated to project work, i.e. They are working as hard as possible on the tasks, with 100% focus and dediction to to the team, with zero distractions. In this theoretical world, their weekly velocity would remain constant. If for any chance their velocity deviates from their established average, even after accounting for absences and meetings, there are two logical conclusions one can draw.
- The 100% estimation accuracy assumption is incorrect.
- The team aren’t 100% committed (either through personal or professional distractions) to the project.
The underlying cause is likely to be a combination of both, however, in my experience it is better to assume the estimates are less accurate, rather than question the commitment of my team, unless I have reasons to believe otherwise, in which case, I’d have bigger problems on my hand.
4b. Story Points do not measure Value
Effort is not the same thing as business value. A team that is “productive” enough to complete 25 points worth of tasks, may in acutality produce far less business value than a less “productive” team that can only complete 10 points.
So are there any benefits?
As mentioned at the very beginning, there is value in Story Points, when only when it comes to high level planning, beyond this there is arguably no additional benefit, only distractions, and misleading metrics.
However, in my experience, the real tangible benefit of estimating tasks and backlogs is that to achieve a consensus on an appropriate Story Point value, the team needs to discuss the task at hand, they all need to understand what is required and they ensure the task is sufficiently defined. It is this understanding and discussion that is the true value of estimating, and not the eventual Story Point value.
Conclusion
The original purpose of Story Points was to provide another tool for high-level project estimates. A tool that can easily adapt the project timeline as the team’s ability to complete work fluctuates. One that wasn’t so rigid that it could adjust the projected timeline as the original estimates changed.
Story Points were never intended to be used as a tool for measuring the performance of a team.
Using Story Points as a mechanism for reporting on, and accounting for team productivity (a hang-over from the early emphasis on Burn-Down Charts), is a misleading metric, and serves as nothing more than a management tool that distracts the team from achieving their goals. That is to provide quality outcomes for the business/customer.
-
|
- Agile |
- Estimation |