Like any project, things happen. How can I plan for contingencies in a Scrum-based project?
My current practice is to have 10% contingency for the whole project, e.g. for a 10 sprint project, we will add 1 sprint at the end. If the team delivers, we use it for the "cool down" period, e.g. training etc. Otherwise, it will be used for catch-up work.
Like any project, things happen. I am looking for feedback on how to plan for the contingency in a scrum based project. [sic]
This is an X/Y problem. In Scrum, you have estimates rather than guarantees, especially at the release-planning level. While you can always apply a fudge factor to any project management methodology, there is no cure for treating an estimate like a money-back guarantee.
Scrum handles project uncertainty by using an iterative development model, and by re-planning the project at the start of each new Sprint to take advantage of the most recent information about the project's needs, the capacity of the team, and the level of effort required to perform the current work increment. Contingency planning is thus reduced to an exercise in managing scope and quality, rather than trying to guesstimate the right fudge factor upfront.
My current practice is to have 10% contingency for the whole project, e.g. for a 10 sprint project, we will add 1 sprint at the end.
If you have an extremely mature Scrum team with a stable velocity range, this may work with smaller projects where the scope of the work is exceptionally well-defined. Generally, though, this is a "project smell" that indicates that Sprints are being misused as milestones rather than as time boxes.
A Sprint is an ephemeral time box with an estimated capacity that varies from iteration to iteration, but generally fits within a normative range over time. However, treating Sprints like fixed-scope, fixed-deadline milestones creates all the project overhead of Scrum with none of the benefits, and is unlikely to succeed in any but the simplest projects.
Given the standard project management constraints of scope, schedule, and budget, Scrum project planning generally involves making scope the flexible constraint. In other words, the iterative development paradigm generally says:
Given a fixed delivery date of ten weeks from now,
And given the budget for ten weeks of sustainable agile development
When the developers are given a Product Backlog that exceeds their available capacity
Then the scope of Product Backlog Items will be reduced until they fit.
Alternatively, using other methodologies like Kanban you could make schedule the flexible constraint and simply estimate your delivery date (and your budget) as a slope function of the size of your Product Backlog, your average cycle time, and your mean throughput. In other words, you estimate when the project will be done based on how long it takes you to do the work, rather than estimating how much work can fit into your release schedule.
Scrum and other agile methodologies are based on the idea that you can't accurately estimate level of effort more than one or two iterations in advance. In Scrum, release planning is generally based on a rough first-pass estimate of all Product Backlog Items. This estimate must be done by the development team, of course, not the management team!
The Product Owner then works with the team to select the Product Backlog Items that might be expected to fit within the time box defined by the release schedule (e.g. 10 iterations), adjusting priorities and scope on the fly if needed. Then each Sprint, the Product Owner and the team meet during Sprint Planning to re-plan the current increment. This gives the Product Owner the chance to re-scope and re-prioritize the Product Backlog in order to get the most value out of the current Sprint and the product-release time box.
If you are doing a lot of up-front planning with fixed specifications and a fixed schedule—plus probably a fixed budget, too—then you aren't doing iterative development. That's okay; 32% of non-agile projects still succeed!
If you want to be a Scrum shop, you have to accept the tenets of the framework. If you can't do that, then you can save yourself a lot of long-term pain by not trying to "be agile." Just say you have a 10-week project with a 10% allowable variance, track your progress against your project's tolerances, and keep management informed.
Twiddling your "allowable variance" won't make you agile. However, a sufficient buffer will provide some cushion when unplanned work or unexpected complexity throw your carefully-scheduled project out of tolerance.
The short answer is that the project plan is more emergent than that - allow me to elaborate.
In scrum I have a constantly evolving backlog. I work with the team to identify what work will be done in a sprint and we take that work to completion, but during that time, the product backlog could be changing with items being added, removed, or reprioritized. Also, at the end of the sprint, hopefully I'm getting feedback about the work I completed that also affects the backlog. While it's hypothetically possible that my backlog would never change from start to finish, it would be a big red flag for me that the team is sticking to their plan over adapting to customer needs as we go.
Because the team should complete each backlog item entirely in the sprint and you have the ability to include feedback and learnings from sprint to sprint in the product backlog, the contingency time is built into the process rather than needing to be allotted at the end.
Reading into your question a bit
In traditional waterfall project management, we have a fairly set scope and at least an expected completion time, which I think is the mindset you're coming from when you say "for a 10-sprint project". Normally you would build in buffer to account for unknowns, or as you put it, contingency.
Scrum takes a different approach. I have backlog items or, at a higher level, features that I would like my application to do. I may think the project will take 10 sprints, but if after the 3rd sprint I'm averaging 3 completed per sprint and I had 50 total, I already know my expectation is way off (in 10 sprints I'd have about 30 done, give or take) and I take action immediately. That action could be many things - canceling the project, changing expectations, starting up another team, etc.
Again, my plan comes together and evolves as I learn rather than leaving room for it at the end.
Hardening Sprints
Finally, another common circumstance with real-life application of Scrum is that teams often can't get backlog items complete in a sprint. Maybe it's a problem in the team they haven't worked out or maybe it's an organizational constraint like all software changes have to go through a month-long review and deployment process. Ideally in Scrum (or any Agile approach I can think of) this shouldn't be a problem, but it is. Large organizations are slower to change than small teams. A common work-around is something called hardening sprints. This is some time you take every few sprints to shore up all of the loose ends.
I used to fight against these pretty hard, but they work ok if you understand what their use is. They're a lot like crutches. You wouldn't give someone with a broken leg a crutch and say "You're better now." They get you through a tough time, but if your end-goal is not to eliminate the need for them, you've got a rough life ahead of you.
