In 2015, I successfully accompanied a great number of teams towards agility. I remember one particular moment, before I started coaching and evangelizing on Agile virtues, when a colleague came to me and said “Martin, this point stuff is crap and it’s a waste of time…”. Just to emphasize is opinion further, he added; “I really don’t get it and good luck explaining it to us”.
You know what, I like challenges!
Before I go through how I present the ideas, let’s step back and review why. To begin with, let’s discuss why we should attempt to work with Story Points.
To understand Story Points, we have to talk about relative estimation. For the sake of avoiding some of the pitfalls associated with estimates and seeking unnecessary precision, the different lightweight methodologies have been promoting the psychology that people are far better with comparison than with absolute measures.
Mike Cohn, in the book “Agile Estimating and Planning” uses dog and zoo points to illustrate the concepts of relative estimation. I was so fascinated with these concepts that I decided to complete my Product Owner certification with Mike in his CSPO class (and had the opportunity to share a story of mine on his blog). In training, Mike spoke about how long it takes to complete a User Story with the influence of complexity, uncertainty, risk, volume of work, etc. The example used was “How long will it take to read the latest Harry Potter book?” To estimate this task, we compared this book to the other Harry Potter books. Everyone had different results! Interesting dilemma, don’t you think?
On a personal note, I love running and have completed some great events in the past years. I enjoy using the analogy of a runner over a defined distance (inspired from Mike). Let’s say we have a 10 KM race to undertake, how long is it going to take you? The time it will take me will probably differ from your evaluation. I could say 50 minutes while your estimates could be over an hour – depending on your skills. The problem is, we are both right! So how should we estimate this?
Trying to put a time estimate on running a distance is difficult because we run at different speeds and we could have unplanned surprises. You and I may agree that the distance is 10 kilometers but we may disagree on how long it will take each of us to complete it. We can apply the same concept to work because Story Points serve much the same purpose. They allow individuals with differing skill sets and working speeds to agree. Instead of a fast and slow runner, Mike would say to consider two team members of differing productivity.
Relative estimation works better because developers tend to compare only one dimension. I advise my teams to add multiple dimensions and to start comparing and classifying items in containers of complexity. The containers should contain elements of similar dimensions. A simplified representation of complexity could go this way:
Here are examples of dimensions I propose:
- Effort needed (time to execute the solution)
- Impact on other systems
- Complex to understand
- Smaller set of acceptance criteria
- Quantity of tasks
- Prior experience doing something similar
- How volatile and vague
- Dependencies are at low risk
- Knowledge of technology
- Data quality
- Testing scenarios
I then use those dimensions in my generic estimation workshop. With the contribution of the team, we start grouping details of complexity and build a matrix for arguments over the size of a point. This is a fun activity by the way!
To add some metrics to the activity, we use the Fibonacci sequence. Whenever you sum up the two previous numbers you get the next one in the sequence.
The standard Fibonacci goes 1-1-2-3-5-8-13-21-34-55-89 and so on. In Scrum, the Planning Poker makes use of this sequence with the adapted series: ½-1-2-3-5-8-13-20-40-100.
We now have a common scale for estimating the value to be delivered. The sum of all Story Points delivered in a sprint, will help over time to estimate the team velocity.
Ken Ruben from Innolution defines the velocity to be: A measure of the rate at which work is completed per unit of time. Using Scrum, velocity is typically measured as the sum of the size estimates of the product backlog items that are completed in a sprint. Velocity is reported in the same units as product backlog items—usually story points or ideally, in days. Velocity measures output (the size of what was delivered).
Back to running with velocity, let’s adapt it to my marathon. To survive, I break the distance into 4 iterations. Each has specific objectives and difficulties and I should be able to deliver a number of kilometers in each.
In this example, my velocity should be around 10.4 km/h. It represents my overall speed over my 4 iterations and I should be able to predict when I will be crossing the finish line. Note that I will only know my real velocity until I go the distance and live the pain. LIVE THE PAIN.
The number of Story Points a team delivers over iterations becomes the velocity which has a real value only over the course of several iterations.
Coming back to my incredulous colleague, I managed to quickly demonstrate with stellar deliveries the concept of a point. The ability to predict how much work the team can deliver was a winning factor. Defining a common understanding of what a point represents, and what needs to be done to deliver the points was a critical aspect for success. For other teams still in traditional mode, it looks like sorcery, but there is no magic, good execution will get the job done!