Some Practical Advice on Agile Project Contingency

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’

PaddingVSContingencyThe 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.

Tagged , ,

6 thoughts on “Some Practical Advice on Agile Project Contingency

  1. Matt Law says:

    Absolutely love it 😀

  2. PM Hut says:

    Hi Theo,

    The contingency section is spot on. Most project managers add anywhere between 50% to 100% contingency to their schedule/costs – this is not good as it strips the “sense of urgency” from the project and the project will suffer from “Parkinson’s Law”.

    PS: I really like your post and I would like to republish it on PM Hut where many project managers will benefit from it. Please either email me or contact me through the contact us form on the PM Hut website in case you’re OK with this.


  3. Attractive section of content. I just stumbled upon your
    blog and in accession capital to assert that I get actually enjoyed account your blog posts.
    Anyway I will be subscribing to your augment and even I achievement you
    access consistently fast.

  4. Chris L says:

    Regarding Mr. Injections post – ‘My hovercraft is full of eels’ – I guess Google translate is the modern version?

  5. ちょう says:

    Thanks for a marvelous posting! I definitely enjoyed reading it, you
    will be a great author.I will always bookmark your blog and will eventually come
    back in the foreseeable future. I want to encourage one to continue your great work, have a nice weekend!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: