Some Thoughts on Project Velocity
Companies I work with desperately want reliable estimates.
In reality, they need them so they can run their business. Businesses really want a crystal ball to look out into the future… to know pretty much what they are going to get, when they are going to get it, and some idea of what it is going to cost. The problem is that they need this information when approving projects… when making commitments to the market… and this is when we have the least reliable information about what we are building.
This need can result in pretty bad behavior on the part of both management and teams. To gain some sense of certainty, management does things like ask teams to provide estimates in real hours… and then hold the team accountable for delivering exactly according to that estimate. Faced with an impossible situation, teams are incented to game the numbers. They overestimate the project (to provide some necessary buffer) thus resulting in overinflated budgets. All this leads to a total lack of trust on both sides.
Velocity is intended to bridge the gap between management and the team. Teams get to measure project scope in relative units such as story points. Point estimates are specific to the team and measure how big one feature is relative to another in the backlog. Teams then begin building the features and measure how much of the backlog they are able to complete every iteration. After a few iterations, the team should have a pretty good idea how long it will take to complete the project.
Iterations to Complete = Backlog Size/Points per Iteration
For this equation to work, for velocity to be a meaningful metric, it has to be predictable… past performance must at some point become indicator of future performance.
Furthermore, velocity is only relevant to the business if we have a decent understanding of the overall scope of the project. That means we have to have a meaningful view into the backlog… for at least the upcoming release… sometimes the entire project. Measuring velocity against a constantly changing backlog doesn’t give me a whole lot of information. If we are going to have any idea of what done looks like at the project level, we need to understand both backlog size and velocity… and understand how these metrics might change over time.
Velocity is fundamentally a measure of team throughput. How fast are we able to go… iteration over iteration… against a relatively stable queue of product features. These two metrics are the only thing standing between an agile team and total choas… at least when it comes to overall project performance.
To make all this work… both sides have to do their part. Ask not what your agile project can do for you… ask what you can do for your agile project. Here are a few thoughts on what managers and teams can keep in mind to keep velocity a reliable indicator of project performance… and maybe build a little trust while we are at it.
Responsibilities of Management
Realize that estimates are just that, estimates. As management, we can expect that estimate should get better over time, but what we get early… even in story points… is likely to change. We need to be prepared to deal with change.
Management should only use metrics like velocity as an indicator of project health and to help guide the project into a successful outcome. If management uses velocity as a lever or a performance metric, people will game the system to make the numbers look right. You’ll get the numbers you want, you might just not get the product you want.
The size of the backlog has to be stable or the project is out of control. We can’t just keep changing our minds indefinitely. We want to defer as many decisions, as long as possible, but we need to have a fundamental understanding of the product we are building and why. Constant churn will slow the team down and make everybody frustrated.
Responsibilities of the Team
Estimates are just that estimates. That said, we are accountable for making them better over time. At some point we have to be able to tell the business what they are going to get and when they are going to get it.
As team members we have to realize that our velocity must stabilize. Stable velocity is the life-blood of a predicable agile team. If we can’t stabilize our velocity, the business will always see our project as out of control… because it is. We cannot expect the business to continue to invest never knowing what they can expect to be delivered.
We have to be honest with ourselves and our customers about what it really means to be done at the end of an iteration. Gaming the system to make the numbers look right will kill a project… hiding undone work in future iterations doesn’t help either.
For Further Reading:
A little more on the idea of uncertainty and the reality of progressive estimating:
http://blog.softwarearchitecture.com/2008/03/progressive-refinement-of-estimates-aka.html
Some of my thoughts on team accountability and the need to accommodate change:
https://www.leadingagile.com/2009/01/what-about-accountability/
https://www.leadingagile.com/2008/07/delivering-value
Comments (8)
JH
Iterations to Complete = Backlog Size/Points per Iteration
Does this mean that there’s little to no way to estimate completion until a full backlog has been created and estimated?
joapen
Hello,
thank you for your thoughts.
Something interesting about estimation is to define the RACI chart: Who is Responsible, who is accountable, who is consulted and who is informed. When I do this excercise with the team, they get surprised.
Regards
Mike Cottmeyer
JH,
My off the cuff answer is that, with agile, you always know when you are going to be done. The time is fixed (release date). So is the oost (team size). What we can vary is scope (the backlog). Velocity tells us how fast we are moving through the backlog, and thus, how much we can get built before we run out of time and money.
That said, it seems pretty straightforward to me that you will not have any idea of what you will be able to build for that time and money until you have a pretty good idea of your backlog.
Some teams are able to get away with a high level statement of direction that allows the product owner and the team to converge on a solution that delivers the highest value possible. If you have that, and the business is generally happy with the outcome, more power to you. I think that would be ideal.
Most enterprise agile implementations, there needs to be more coordination between teams and therefore, more backlog planning is necessary.
Personally, I am a fan of a fully defined backlog before we start the release… after all, that is the scope of the project.
Are we going to change, sure… but that is why we write the backlog in stories and estimate in points… so it is lightweight and resilient.
So… I would say that you will not know how much of anything you are going to be able to build, until you determine what it is that you want to build, and that is the backlog.
Mike Cottmeyer
Thanks for the comment joapen. I bet that exercise is eye opening.
I wrote this post after reading several articles that basically said… we are agile, we don’t plan, velocity can be all over the place, that is just the way it is. Any attempt to measure velocity or influence it will lead to gaming the system.
Basically what folks like that are saying is: we don’t want to be accountable, leave us alone and let us do the best we can do. That may work in some environments, but it won’t work in most.
At some point we have to understand the dynamic relationship between time, cost, and scope. We have to manage these variables no matter if we are traditional or agile. Failure to describe the requirements, or only defining them a few weeks at a time, IMO, is irresponsible.
JH
My biggest complaint about agile projects has been the same as other iterative processes. A lack of pre-planning (pre-iteration planning meeting) to establish a backlog/plan simply doesn’t exist. In my experience, this has been the biggest ball dropped by most scrum masters/iteration managers/project managers. This problem, inevitably, leads to lengthy meetings with a LOT of waste for a LOT of people which then leads to disgruntled people on all sides.
Mike Cottmeyer
The trick is to do just enough of that planning up front to provide structure and direction, but leaving as many decisions open as long as possible. For a little more on this check out my latest post:
https://www.leadingagile.com/2009/01/progressive-estimation-and-tollgates.html