Planning for Uncertainty

From the Agile Thoughts Blog
This blog represents everything agile. Agile thoughts, issues, concerns, experiences, etc. I want to share and provide an outlet for the agile mindset. "Don't just do agile, be agile".

About this Blog


Recent Posts

Implementing Programs in Scrum

Regression Testing in Scrum

Planning for Uncertainty

Task Estimation with Scrum

Scrum Guidance Body Recommendations

Categories: Agile, Planning, Uncertainty

Agile projects often have a high degree of uncertainty; namely, there are absent features and time estimates that have a high probability of adversely impacting the business. To avoid a negative impact, estimates should be buffered to reflect levels of uncertainty that are intrinsic in estimation activities. This article is a discussion of the various types of buffers used to minimize uncertainty during planning with Agile Methods.

Sprint Planning Buffer

The rationale for conducting an Agile Planning meeting is for the purposes of presenting the User Stories to the Agile Team for estimation. The outcome of this meeting is the team being aligned with the business objective. The team is expected to be committed to accomplishing the work required to complete the User Stories in the Sprint Backlog. The first and most important process in the Agile Planning meeting should be determining the team’s velocity. Methods for calculating the team’s velocity include but are not limited to the following.

  1. The team’s capacity can be calculated based on the following formula:
    1. (Number of team members) X (Number of days in the iteration) X (6 hours)
  2. During the Planning meeting, team members who have planned vacation time during the approaching Sprint should be identified and captured as a “vacation user story”. This user story should have tasks that represent each team member’s time out of the office. This will account for some of the team’s velocity, represented as user stories during the committed process of planning. Once the Sprint is in progress and the vacation days have approached, the burndown chart will reflect the vacation days tasks as being completed along with other tasks. The burndown chart will correctly reflect the team’s velocity due to vacation and time away from the office. As an example, we use a six-member Agile Team that is planning a 10-day Sprint to calculate the capacity of the team:

(6 members) X (10 days) X (6 hours per day) = 360 hours capacity.

The daily burndown is then calculated as (360 hours of capacity) divided by (10-day Sprint) is equal to 36 hours.

The Sprint capacity is determined using the assumption that all team members have only six-hour available hours to do work per day. This is a Sprint Planning Buffer that keeps the team from being over-obligated. This approach takes into consideration all team disruptions such as lunchtime, meetings, and any time away from the office. This buffer is applicable to Lean Software Development under the principle, “Limit work to capacity” which helps to ensure a highly productive and sustainable development pace.

Feature Buffering

Features have changing levels of importance to customers, and they represent the “must haves” and the “should haves”. An agile project is planned with the intention of delivering functionality and providing flexibility. The customer identifies the features that the project is required to deliver based on business value and then continues this process until most of the remaining work that is non-critical has been selected. During the process of estimating all user stories, it will become clear that the project will be besieged. This will require the removal of the additional features from the schedule so that the project will get back on track. The percentage of additional features to be included is based on the magnitude of uncertainty that needs to be buffered and the project size.

Schedule Buffers

To inject a buffer into the project schedule, the level of uncertainty needs to be identified. We should not randomly apply padding into the schedule, rather we should establish a valid range. To be more accurate with our uncertainty calculation, we need to start with two distinct numbers for estimation purposes.

  1. Our best uncertainty estimate is the 50%, which mean that there is a 50% chance that the project is finished on time and a 50% chance that it won’t be.
  2. The worst uncertainty estimate is the 90%, which represents a 90% certainty regarding the time needed to complete a task. The additional time in-between the estimates is referred to as a local safety value.

If we add up all local safety values and use them as buffers, it will be inaccurate because it’s not probable that things will go incorrectly to this extent. Using two estimates is a better approach because it represents the uncertainty in the estimate and this allows us to come up with the risk linked to each user story. When we buffer our project to our 90% certainty estimate, we need a buffer that has two standard deviations. This means that we calculate the following:

  1. Determine the local safety value for each feature
  2. Square each local safety value
  3. Total all squared local safety estimates
  4. Calculate the square root of the total
  5. The residual number is the buffer estimate and is added to the initial estimate to calculate a range.

 See Table 1 below for an example:


Average Estimate (50%)

Worst Estimate (90%)

Feature 15



Feature 16



Feature 17



Table 1. User Story Best & Worst Estimates

Our calculations are shown in Table 2 below.




Local Safety

Local Safety Squared

Feature 15





Feature 16





Feature 17









Square Root





Combining Buffers

So that we experience as much risk reduction as possible, it is helpful to combine buffers. This means that we could indicate that our project will finish the following:

  1. All Core features
  2. Between 0% to 100% of extra features
  3. The features will be finished during a point between the original estimate and the buffered estimate. This is done to give customers more flexibility when calculating the end date for the project. Figure 1 is an illustration of combining buffers.

Figure 1. Combining Buffers


Mining Code. (2014). Agile Planning and Estimation. Retrieved from

Scrum Alliance. (2008). Perfect Planning. Best Practices for Successful Planning. Retrieved from

Posted on: September 16, 2018 07:17 PM | Permalink

Comments (13)

Please login or join to subscribe to this item
Very informative and useful.
Thanks a lot!

Very useful. Thanks so much!

Interesting strategy. I have used [somewhat] similar exercises in determining estimates.

Thanks, Denise.

Denise, I always enjoy going through your blogs. They are very helpful and I am sure new ACP aspirants will find them very useful too. Keep them coming, maybe even write a book.

Thank you for the feedback!

Very interesting article, thanks for sharing...

Interesting information! Thanks for sharing!

Useful and practical information. Thank you for sharing this with us with such details.

It's ok for velocity to be "out there" a little bit at the start. No one expects it to be that accurate, but they will expect it over time. Thanks Denise.


I just happened to find your article in search of candid conversation about the Agile approach to project management. Your article is very insightful with rich detail and clarity. Thanks!

Being new to the Agile approach myself, I was hoping to get some insight on how to convince a potential customer who is unfamiliar to Agile about using Agile methods for her/his particular project. I’m really not sure how to articulate the learn and adapt approach to someone who feels more comfortable with the predictive approach. The area of the conversation with a potential customer that I'm struggling with is what the expense structure would look like for interative processes from start to completion.

Please Login/Register to leave a comment.


"Let us be thankful for fools. But for them the rest of us could not succeed."

- Mark Twain