In a perfect world…
…the life of a Scrum Master is bliss. We don’t pretend we know everything in advance, we don’t pretend we are in the head of the Product Owner and we are always honest about the real state of the product/development lifecycle through open demos, retrospectives and openly-publicized metrics.
We constantly dedicate our time to improving performance and delivery of value through best practices, continuous improvement, and collaboration with all the relevant stakeholders.
Until one magical day, after a lot of iterations, we reach Agile Nirvana and can predict accurately the amount of work we can deliver in the… next sprint! (That’d be 2 to 4 weeks – hardly something to write home about….)
But organisations don’t operate in sprints – they operate in quarters or years and more often than not, senior management is interested in knowing what you can deliver in the next X number of months.
That’s the point when all Scrum Masters start pulling their hair out, screaming that “this is not how Agile works” and curse about the travesty that is “agile waterfall-isation”. We keep kicking and screaming up until the point we realise that the managerial demand won’t go away and we start Googling advice from Agile Gurus on how to perform Project Planning on an Agile Environment.
Now, the purpose of this post is not to explain how to estimate and plan an Agile Project – there are a lot of people out there who can explain this a lot better than me and have done so already. The purpose of this post is to showcase my personal, straight-to-the-point advice on Agile Project Contingency and its role/importance in said environment.
So let’s get some facts straight…
‘Contingency’ is not ‘Padding’
The addition of Contingency to the estimates is due to the recognition that we are operating in an Agile Environment where we don’t pretend that we understand everything from day one. The term “padding” applies to cases where we are very confident with the estimate of a task but we still choose to add some extra time, just in case it rains in Beijing on the release day/the internet disappears/the cockroaches rise and take over the world.
Contingency is for the unknowns…
…and not for the tasks that we can’t be bothered sizing. It might be hard to estimate the effort required for bug fixing and live issue support but we know that those things will knock on our door at some point in the sprint(s). The effort required might be unknown/hard to estimate, however they are not unknowns themselves! Do not leave those items un-estimated thinking that they will be “caught under the Contingency Umbrella”.
No one will tell you how much to add
There’s no rule of thumb regarding how much Contingency you should add to your estimates; it varies by organisation, team, as well as the nature of the work. Anecdotal whispers “through the grapevine” suggest that 40% Contingency for relatively mature agile teams is about right.
Do track your Contingency throughout the Project
Don’t assume that the addition of a generous Contingency will see the project to the end. Like everything else in Agile, your Contingency assumptions should be constantly monitored throughout your project and adjusted accordingly.
With small chunks of the backlog sized in detail before every sprint (as a minimum), it is easy for us to plot out the progress of the backlog size throughout the project duration and establish if the contingency we have added is over- or underestimated.
In my opinion, all the above are just common sense and in-line with the Agile Principle of “Inspect & Adapt”. The challenge in a real working environment is convincing your project sponsor that Contingency is not padding, nor that it indicates an inability to complete a decent planning session. Whilst more and more non-technical stakeholders claim to understand and support Agile as an organisational philosophy, I am yet to be convinced that this understanding “trickles” all the way down to the day-to-day tasks.