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.
You Can't Do Fixed-Scheduled and Fixed-Scope in Scrum
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.
Understanding Constraint Sliders
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.
Not Doing Scrum? Do Something Else!
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.