Planning for Uncertainty

How do Agile Projects help when Planning for 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. Let’s discuss 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 Scrum Team (Scrum Master, Product Owner and Development 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 Planning meeting should be determining the team’s velocity. A methods for calculating the team’s velocity is:

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)

Planning Meetings

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 Scrum 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 hours available 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 lunch time, 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”. A Scrum 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.

We found these books great for finding out more information on Agile Scrum:

Planning for Uncertainty: 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% change 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 are referred to as a local safety value.

Certainty Estimates

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:

Story	Average Estimate (50%)	Worst Estimate (90%)
Feature 15	3	5
Feature 16	5	8
Feature 17	8	13

Table 1. User Story Best & Worst Estimates

Our calculations are shown in Table 2 below.

Story	Average	Worst	Local Safety	Local Safety Squared
Feature 15	3	5	2	4
Feature 16	5	8	3	9
Feature 17	8	13	5	25
Total				38
Square Root				6.16

Planning for Uncertainty: 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

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.