Planning for Uncertainty

Email Notifications

SHARE
Request to reuse this

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:

Table 1. User Story Best & Worst Estimates

Our calculations are shown in Table 2 below.

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

References:

Mining Code. (2014). Agile Planning and Estimation. Retrieved from http://seantrobinson.co.uk/agile-planning-scheduling-2/

Scrum Alliance. (2008). Perfect Planning. Best Practices for Successful Planning. Retrieved from https://www.scrumalliance.org/community/articles/2007/august/perfect-planning