Estimating using Velocity
Estimating in Agile have always been challenging for teams. In this newsletter, we continue the deep dive into agile estimation. Specifically, how to use velocity in estimating.
Velocity and story points have always been a challenge for teams. Agile estimation very much relies on understanding velocity and using it to convert relative estimates into duration and a plan.
Velocity is simply the number of story points that a team can complete in a sprint.
The challenge with velocity is that no two teams have the same velocity. Even if it’s the same team but team members have changed or the technology stack or working environment has changed, all this would impact the velocity.
The second challenge is that different teams have different relative measure of a story point. What is a five-story point user story for one team, may be a three-story point user story for another team.
The third challenge with any estimates is the cone of uncertainty. The cone of uncertainty shows the variability of the estimates at the beginning of the project and how the variability reduces as the project progresses.
Source: Agile Estimating and Planning by Mike Cohn (2010)
It’s important to provide a range in your estimates rather than a specific time frame or date. Otherwise, you’re putting yourself and your team into a world of hurt.
For example, if you had a backlog of user stories that totalled 100 story points and the velocity of the team is 25 story points per two-week iteration, the estimate would be 8 weeks to complete the software. Using the cone of uncertainty model, you would provide a range for the completion of the software.
Before we do that, let’s look at how we can determine velocity.
How do you determine velocity?
In his book Agile Estimating and Planning (2010), Mike Cohn described three ways to determine velocity.
The first is historical velocity for the established team. But if any parameters change, this will add variability to the historical velocity. This work well for a persistent team that has worked in a domain area for a while.
The second way is to run one or a few iterations and use that to determine the velocity. If you run a few iterations, you can take the average of those iterations. Most teams may not have the luxury of running one or a few iterations.
The third option is to make a forecast.
Estimate how many hours are available for team members to work on the project. Usually, about 70% - 80% of their time, the remainder is lost through activities like admin, meetings etc.
Estimate the number of hours available in the iteration length. Multiply the hours per person by number of people in the team and the length of the iteration. The most common is 2 weeks sprint (or 10 days). This also assumes that teams are cross-functional.
Grab a cross-section of user stories and break them down into tasks to see how much work the team can fit into the number of hours. From this exercise, you can determine how many story points the team get through in an iteration. remember partial user stories don’t count.
Determining the Range
At the beginning of the project, there is still a lot of unknowns in the software that the team needs to build. By providing a specific estimate and release date, you will put the team in a corner and most likely the estimates will change as for information is found out.
It’s best that the estimate is provided as a range and the cone of uncertainty can provide that range.
For example, the range at the Initial Product Definition would be between 0.6 to 1.6 of the velocity. Using the example above, the range for the velocity of each iteration would be 6 (25 x 0.25 = 15) and 40 story points and deriving the duration, it would be anywhere between 3 to 17 iterations.
As the team moves through the project and finds more information, the range can be reduced. At Approved Product Definition, the range might be 0.8 to 1.5, velocity for each iteration may be between 20 to 37 story points per iteration.
Estimates in the real world
Back in the real world, the Steering Committee and leadership team want to know when the project will be delivered. The team spends weeks providing granular estimates of x weeks of build and y weeks of testing which will be deployed by a specific date.
Most likely, as the team finds out more information and builds the software, there may be delays and the team works overtime to try to keep to the schedule and may have to put in a change request to extend the timeframe or bring in more resources to make the promised date or split the release.
Providing a range that gets refined may save the team this pattern of behaviour and allow them to focus on delivery.
Practice
For the practice this week, try using the cone of uncertainty in your estimation process. Even if the standard process in your organisation is to provide a specific estimate and date for delivery, keep the range estimates in your back pocket and as you progress through the iterations, refine the estimates.
At the end of the project or release, review the estimates that you made throughout the project and the estimate that you had to provide to the leadership team.
What lessons did you learn from it?
How accurate were your initial estimates from what was delivered?
How can you incorporate the range estimates in your next project?
Drop me a note to let me know of what you’ve learnt from this practice.
Quote
“I judge you unfortunate because you have never lived through misfortune. You have passed through life without an opponent— no one can ever know what you are capable of, not even you.” Seneca
I love this quote from Seneca. It changes how we view challenges, setbacks and failures in our life. It challenges us to see how the challenges, failures, and setbacks improve us, making us more resilient and stronger.
If you’re facing a challenge now or have a recent setback, use this quote to help propel you through the testing time. Ask yourself how this challenge can fortify you, and improve you. What opportunities are available now that you have this setback and challenge?
It may be hard to change your mindset and perspective. Take as much time as you need. Journal it, take a walk and think about it or talk to someone about it.
Interesting Resources - How To Be Awesome At Your Job
A great podcast, by Pete Mocktaitis, that covers various topics on how to be awesome at your job. They have insightful interviews and guests. Topics range from confidence, leadership and thinking. I highly recommend it.
https://awesomeatyourjob.com/
Products to help you
Below are digital products that I have created for you to help improve your craft.
Remember - regular practice improves your mastery.