While planning projects in agile, want to understand the industry standards for estimating agile projects (how much effort is factored as contigency) Saving Changes...
Contingency has nothing to do with a delivery approach - it should always be based on the level of risk related to a project, milestone or activity. Now one difference between projects following a predictive approach vs those following an adaptive one is that those following an adaptive approach might be able to de-risk much earlier which means your contingency amounts would be front-loaded in the life cycle and could be released back to funding authorities once the first critical deliveries of value have occurred
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Some little adjustments must be done. For example, depending if you are following a Lean Portfolio Management (LPM) process or not. In LPM you have permanent teams and things like that. So, my recommendation is taking a look to LPM or other type of process related to portfolio management when using agile approach. At the end, contingency and others are not usually tied to the approach but they are tied to the way you manage the portfolio. Saving Changes...
I will take the more radical position that "contingency" is a strictly waterfall concept that has no place in incremental development. The entire point to contingency is to create a buffer allowing for unknowns that will theoretically allow you to hit long-term cost and schedule targets. Projects for which nonpredictive ("Agile") methods are applicable don't have long-term targets because, by definition, they cannot be predicted, and thus do not need contingency.
...
2 replies by Kiron Bondale and Venkatasamy Ramesh
Jan 24, 2025 11:52 AM
Venkatasamy Ramesh
...
I agree with this answer
Jan 24, 2025 4:34 PM
Kiron Bondale
...
Jim -
Contingency is needed regardless of the delivery approach. One example might be if the team is following Scrum and believes it would take five sprints to deliver an MVP to validate a hypothesis. With no scope to reduce to achieve the MVP, they might add a sprint as contingency in the event that the risk profile of the work is greater than they expect. Similarly, contingency reserves for funding are needed - for example, if an internal team member goes on long term disability and an external consultant needs to be brought in to make the team "whole", the costs associated with that might be offset by contingency reserves.
Kiron
Saving Changes...
Venkatasamy RameshProject Management| TNEB,Saudi Electricity Company -National GridChennai, India
Jan 21, 2025 10:00 AM
Replying to Jim Morgan
...
I will take the more radical position that "contingency" is a strictly waterfall concept that has no place in incremental development. The entire point to contingency is to create a buffer allowing for unknowns that will theoretically allow you to hit long-term cost and schedule targets. Projects for which nonpredictive ("Agile") methods are applicable don't have long-term targets because, by definition, they cannot be predicted, and thus do not need contingency.
I will take the more radical position that "contingency" is a strictly waterfall concept that has no place in incremental development. The entire point to contingency is to create a buffer allowing for unknowns that will theoretically allow you to hit long-term cost and schedule targets. Projects for which nonpredictive ("Agile") methods are applicable don't have long-term targets because, by definition, they cannot be predicted, and thus do not need contingency.
Jim -
Contingency is needed regardless of the delivery approach. One example might be if the team is following Scrum and believes it would take five sprints to deliver an MVP to validate a hypothesis. With no scope to reduce to achieve the MVP, they might add a sprint as contingency in the event that the risk profile of the work is greater than they expect. Similarly, contingency reserves for funding are needed - for example, if an internal team member goes on long term disability and an external consultant needs to be brought in to make the team "whole", the costs associated with that might be offset by contingency reserves.
Kiron
...
1 reply by Jim Morgan
Jan 24, 2025 9:49 PM
Jim Morgan
...
Kiron, I know your description is often true in supposedly “Agile” organizations, but I consider that to actually be a hybrid scenario. In a fully agile organization, the Scrum team is not required to estimate when it will deliver the MVP, therefore there is no need for contingency to make that estimate correct. The team simply delivers working iterations until the customer is happy. I have facilitated this scenario with hardware, software, and administrative teams, improving customer satisfaction in each case.
In the most agile scenario for internal teams, budgeting is not project-based, so the same remains true. The organization has an org-wide annual budget based on labor and materials and lets the teams focus on whatever internal “customers” say will add the most value.
In a customer-paid situation, there may be a project-specific budget cap, but the team merely promises to deliver as much as humanly possible at top quality within the number of sprints the customer (or project sponsor) is willing to pay for. The customer directs the work sprint to sprint through backlog revision and prioritization, aided by the product owner. If the team is approaching the cap, the sponsor can decide whether to just take what will be delivered (which is a working increment, even if not the MVP), or authorize more spending for more iterations.
Contingency is needed regardless of the delivery approach. One example might be if the team is following Scrum and believes it would take five sprints to deliver an MVP to validate a hypothesis. With no scope to reduce to achieve the MVP, they might add a sprint as contingency in the event that the risk profile of the work is greater than they expect. Similarly, contingency reserves for funding are needed - for example, if an internal team member goes on long term disability and an external consultant needs to be brought in to make the team "whole", the costs associated with that might be offset by contingency reserves.
Kiron
Kiron, I know your description is often true in supposedly “Agile” organizations, but I consider that to actually be a hybrid scenario. In a fully agile organization, the Scrum team is not required to estimate when it will deliver the MVP, therefore there is no need for contingency to make that estimate correct. The team simply delivers working iterations until the customer is happy. I have facilitated this scenario with hardware, software, and administrative teams, improving customer satisfaction in each case.
In the most agile scenario for internal teams, budgeting is not project-based, so the same remains true. The organization has an org-wide annual budget based on labor and materials and lets the teams focus on whatever internal “customers” say will add the most value.
In a customer-paid situation, there may be a project-specific budget cap, but the team merely promises to deliver as much as humanly possible at top quality within the number of sprints the customer (or project sponsor) is willing to pay for. The customer directs the work sprint to sprint through backlog revision and prioritization, aided by the product owner. If the team is approaching the cap, the sponsor can decide whether to just take what will be delivered (which is a working increment, even if not the MVP), or authorize more spending for more iterations.
Regards--Jim
...
1 reply by Kiron Bondale
Jan 25, 2025 7:17 AM
Kiron Bondale
...
I would agree that it is less formal, but even in a product (as opposed to project) centric situation, the company might find itself with limited funding for their first or even first few releases. When they pitch their funding needs to outside investors, they have to provide "some" idea as to how much might be required. And that figure is likely to include some level of contingency.
Consultant| Canarys Automation LtdBangalore, Karnataka, India
Contingency planning in agile projects depends on the level of uncertainty and risk rather than the delivery approach itself. While agile emphasizes adaptability, it doesn’t eliminate the need to account for risks or unknowns.
In my experience, instead of traditional contingency buffers, agile projects handle uncertainty through iterative planning, regular feedback loops, and backlog prioritization. Riskier or less defined requirements are tackled earlier to de-risk the project incrementally.
That said, if the project is part of a larger portfolio (e.g., Lean Portfolio Management), contingency can still be considered at the portfolio level to handle cross-team dependencies or unforeseen challenges. Ultimately, the key is tailoring your approach to fit the context and complexity of the project.
Kiron, I know your description is often true in supposedly “Agile” organizations, but I consider that to actually be a hybrid scenario. In a fully agile organization, the Scrum team is not required to estimate when it will deliver the MVP, therefore there is no need for contingency to make that estimate correct. The team simply delivers working iterations until the customer is happy. I have facilitated this scenario with hardware, software, and administrative teams, improving customer satisfaction in each case.
In the most agile scenario for internal teams, budgeting is not project-based, so the same remains true. The organization has an org-wide annual budget based on labor and materials and lets the teams focus on whatever internal “customers” say will add the most value.
In a customer-paid situation, there may be a project-specific budget cap, but the team merely promises to deliver as much as humanly possible at top quality within the number of sprints the customer (or project sponsor) is willing to pay for. The customer directs the work sprint to sprint through backlog revision and prioritization, aided by the product owner. If the team is approaching the cap, the sponsor can decide whether to just take what will be delivered (which is a working increment, even if not the MVP), or authorize more spending for more iterations.
Regards--Jim
I would agree that it is less formal, but even in a product (as opposed to project) centric situation, the company might find itself with limited funding for their first or even first few releases. When they pitch their funding needs to outside investors, they have to provide "some" idea as to how much might be required. And that figure is likely to include some level of contingency.
Kiron
...
1 reply by Jim Morgan
Jan 27, 2025 9:43 AM
Jim Morgan
...
I’m sorry, Kiron, but your description does not align with my experience with startups. Venture capital firms I'm familiar with realize there is no way to predict how much a new product will cost. They organically handle funding in a agile way: fund a little, see where it goes, fund a little more (or not) based on initial results, etc. I would not take an investment from an outside investor who thought predictive project management applies to new product development.
"Ambition is like a frog sitting on a Venus Flytrap. The flytrap can bite and bite, but it won't bother the frog because it only has little tiny plant teeth. But some other stuff could happen and it could be like ambition."
Community Champion
