I always wonder when I see another article about how it’s impossible to do Agile software development on a fixed time/fixed price basis. Especially because I’ve spent 75% of my career doing exactly that. The thing that really gets me is when people write that the only way to do accurate estimation is to have complete and detailed requirements up front. As if having 400 pages of cut and paste business speak to adhere to is going to magically solve the problem.
The interesting thing about doing fixed time, fixed price agile development is that it’s just agile development turned out to 11. All the same practices that you should do when doing any flavor agile, but usually don’t are critical to working fixed price. Probably the key practices to follow are: tracking velocity, scope management and multi-sprint strategic planning.
I realized after starting this that this is a big topic and should get split into multiple parts. So here’s the most important, or at least first part.
Tracking Velocity
Hands up how many people actually track velocity? Oh look, no one. People don’t really talk about velocity anymore, it’s not a sexy metric because it tells you the honest ugly truth. The best definition of velocity that I’ve seen is here: Velocity.
Velocity is really just the accuracy of your estimates. People hate to use velocity. If you actually calculate it as a ratio for a sprint:
Work Completed
Ideally the ratio should be 1. If it’s off by more that 10%, then you have some adjusting to do. In my experience that ratio is hardly ever less than 1. It’s just human nature the work will expand to fill the time allowed.
The flip side of this is much more common, the over-commitment problem. Part of this is that developers are optimists. As a developer, we like to say things will take less time once we understand what needs to be done. As a project manager, we have the temptation to try and squeeze one more item into the sprint because it looks like someone isn’t 100% allocated. These two forces are kind of like the wonder twins of project fail.
The reason that it leads to project fail is that it causes unfinished work at the end of the sprint. So, we carry over the uncompleted items into the next sprint, add a couple of new items and keep chugging away. Seems like a reasonable plan.
Q: If you’re delivery is only 75% of the items committed to a sprint, how many sprints will it be before you are a full sprint behind?
A: Three.
For example, your team thinks that it can commit to 40 points worth of work per sprint, but only get 30 done. So sprint 1, you commit to 40, deliver 30 and carry over 10 points. Sprint 2, you have the 10 points of carry over, 40 points of new stories, deliver 30 points of value and carry over 20 points. Sprint 3, you have 20 points of carry over add 40 points, deliver 30 points of value and carry over 30 points.
How many times have you heard “We don’t really have that much to finish up for this item. it should be done really quickly”, or some variation of that. That’s the usual effect of familiarity making the estimate smaller. AKA, what got you into this problem in the first place.
The Cure
The harsh light of truth. There is no easy answer other than open and honest communication. You, meaning the entire team, need to get up in the daily stand up or in the worst case the sprint retrospective and say, “The velocity on this task was 1.5. How can we fix it going forward?” At the very least, we should be asking in sprint retrospectives how to move the velocity ratio closer to 1.
The easiest fix is the “yesterday’s weather” approach. If the team delivered 30 points of value in a sprint, the capacity for the next sprint is 30. Kind of a no-brainer.
The more complex solution is to start looking at the estimates. If we’re only delivering 75% of what we think we should then adjust the estimates up by 33%. This approach works great if you have the backlog already estimated and don’t mind going in and adjusting all those numbers. Me, I have better things to do with my time so I prefer to adjust capacity instead.
The most complex, at least in terms of playing politics instead of getting work done, is root cause analysis on the outliers. The temptation is to call the estimation failures, but this automatically puts people on the defensive and starts up the blame game. If you have a team that’s totally secure and devoid of ego in their work, then it pays off beautifully. Meanwhile in the real world it’s a tough route to take. The upside is that you get to the cause of the problems and can deal with them quickly.
In a nutshell the key to doing fixed time, fixed price agile development is to know how quickly the team is really moving. If you don’t know how fast you’re going, steering the project is going to fail.
Scott's Thoughts 