Your team is transitioning from a world full of Gantt charts and network plans to a new world, the world of agile delivery, where no planning is required! Even better than the abandonment of all requirements gathering and documentation tasks, your work is no longer tied to a time-based estimate. Which of course means the elimination of delivery accountability. Hurray!
There are a lot of moving pieces in a team’s agile transformation puzzle. While each piece is critical, I am going to focus on one that I believe doesn’t get the attention that it deserves: relative estimation of user stories. Relative estimation, conceptually, is pretty simple. The practical application of this estimation method is another story altogether. Once you finish reading (and sharing!) this blog, if I’ve done my job, you’ll have a much better grasp on what is meant by ‘relative’ estimation, why this estimation method is valuable, who should be involved when estimating and most importantly how you can enable successful team adoption. Spoiler Alert: there’s no magic involved unless you think math is magical. In that case, you’re in luck!
What is it?
Relative estimation is based on an abstract unit of measure called story points. Story points provide context about the difficulty level of a story. Often, story points are employed using the Fibonacci sequence. In the Fibonacci Sequence, each number is the sum of the two numbers that precede it.
Fibonacci Sequence: 0,1,1,2,3,5,8,13,21,34,…
If you’re a math nerd like me, you know that the Fibonacci sequence is essentially the numbering system of the universe. It’s represented everywhere you look in nature: flower petals, pine cones, even in the Milky Way galaxy’s spiral shape. The idea behind employing the Fibonacci sequence as the unit of measure for relative estimation is that the difficulty of user stories can be thought of as additive blocks, i.e. a 2 point user story is twice as difficult to deliver as a 1 point user story, a 3 point story is three times as difficult, etc.
Also, notice the lack of time-based context in the story point concept. This is intentional, as the estimation thought process shifts from “how long will this take?” to “how big/difficult/complex is this work?” Reference the example below, and note how the story points assigned increase as the complexity inherent in the construction/delivery of the vehicle increases. When you are estimating agile user stories, you would ask yourself “Am I building a bicycle or an airplane?”
Why is it important?
In any agile delivery team, consistency is the name of the game. Why is consistency so important? Consistency drives predictability, which in turn enables more effective management of customer delivery expectations. The foundation for delivery consistency is user story estimation.
Consistency + Predictability = Happy Customers
What happens when this consistency breaks down? If your user story estimates aren’t consistent, your delivery (known as velocity in the agile world) becomes less predictable and your ability to meet your customer’s expectations is diminished. More often than not, teams overcommit in this scenario and customer expectations soar. In order to meet these now sky-high expectations, teams engage in a herculean effort to deliver value for their customer. This leads to a host of negative outcomes: stress, long hours, and the inevitable uptick in defects to name a few.
Who is involved?
Everyone. All team members are involved in the estimation process. The resulting collaborative discussion is critical to gaining a mutual understanding of both the requirements and the prescribed solution. Each team member walks away with a much clearer picture of the customer expectation, and the development activity inherently required for delivery.
Engagement + Transparency + Healthy Dialogue = Buy-In, Trust and Engagement
How can you enable success?
Find your team’s sweet spot! “Okay, but how do I do that?” you might ask. Here are a few suggestions for how to best employ this powerful estimation tool:
- Find the smallest story in the backlog and assign it 1 point. Then, use that story’s complexity to estimate future stories, leveraging the Fibonacci sequence (1, 2, 3, 5, 8, 13) and the examples referenced above.
- Consider the following characteristics when estimating stories:
- Complexity – How technically complex is the work?
- Risk – Has the team ever done this type of work before?
- Implementation – Is a mission-critical platform or service being replaced?
- Deployment – Is the release window constrained by platform uptime SLAs?
- Interdependencies – Are there cross-team dependencies required to complete delivery?
- Lastly, don’t forget about story point estimation in your Retrospectives!
- Use the retro as an opportunity to review previously estimated stories, re-calibrating the relative estimation guidelines as needed.
If you are already using relative estimation successfully in your agile team, great! Hopefully the information I shared will help you refine your existing processes and improve your team’s velocity. If you aren’t using relative estimation and are stuck in man-days, or even man-hours *gasp*, then you now have a template to set you on the path to delivery excellence. Ultimately, through the adoption of a collaborative, transparent relative estimation model your team will abandon the ‘just survive!’ mentality and begin to thrive.
