Are You Writing Checks Your Team Cannot Cash? Here’s How to Stop Over Committing on Sprints

One of the top 5 mistakes Agile teams make is to over estimate how much work they can deliver in sprint.

Is this due to customer pressure, a desire to please, a hero mentality, or pressure from a manager? I see all of these items being a factor, but I believe the main issue is a lack of knowledge. Specifically, teams are bypassing a critical process, sprint planning.

In my experience teams often talk about story points and how they use them to estimate project releases and sprints. You can see how story points are used to create release plans in my previous article here.

Click Image to view larger.

The disconnect usually comes from the fact that Agile teams often assume that story points are the only way you estimate how much work can be completed in a sprint. In reality, story points are only used to determine which stories to take into sprint planning. At the conclusion of sprint planning we have identified and estimated all known tasks needed to deliver each story, and we compare that to true team member availability.

Click Image to view larger.

At this point the team makes the decision on whether the work will fit, and whether they will commit to the stories scheduled for the sprint. They have much more detailed information to make a commit decision with. Whereas story points indicate impact to the whole team, sprint planning identifies impact to each individual or functional group.

To understand this better, let’s look at an example of how we do sprint planning.

Sprint Planning Overview

If we go back to my previous article, we had a release plan based on how many story points we believed we could complete in a sprint. See figure 1.

We estimated story point velocity to be 25 points per sprint, so each sprint has 25 points or less assigned. In sprint 1 we assigned 22 points that tie directly to 4 user stories. At this point most teams stop. The team assumes they can do the 4 stories and they start sprint 1. This is a huge reason why teams over commit on sprints.

Story points are used for high level estimation and for long term planning. They are a starting point in the planning process and they make perfect sense for estimating how many sprints will be needed for a project.

They estimate effort needed by the whole team.

But if the team is going to commit to a sprint, meaning to provide a personal promise, then they should understand what they are personally being asked to deliver before they make a commitment. We do this by performing detailed planning for a given sprint.

The steps for detailed sprint planning are:

1. Identify the stories to bring into sprint planning
2. Design each story
3. Identify and estimate the specific tasks for each team member
4. Determine team member availability during the sprint
5. Compare the task estimate to team member availability
6. Team makes a commitment based on whether the work fits

Let’s look at each step.

Sprint Planning in Detail

Step 1: Identify the stories to bring into sprint planning.

This is relatively easy. The release plan you have already created indicates which stories to plan for the sprint.

Step 2: Design each story

Designing a story usually means finalizing the coding approach and the visual design. An overall, high level design for the project was created during release planning. Sprint planning builds on this foundational design, with specific details for each story. If you are familiar with JAD (Joint Application Design), you will find sprint design work to be very similar. You will leave sprint planning with detailed screen, coding design, and acceptance criteria for each story.

Step 3: Identify and estimate the specific tasks for each person

After the design is finalized, each team member should identify their tasks, and how much work they need to do to support each story. Here is what the task list and estimates might look like after planning all of the stories in a sprint. See figure 3:

Click Image to view larger.

Step 4: Determine team member availability during the sprint

Once we know how much work is needed, we need to determine how much time each person truly has available to work on the sprint. To keep our example simple, we will assume that our example team performs one week sprints. One week usually means 40 hours of work. So for each team member we should have 40 hours for each of them to deliver their tasks. If you look at the task estimates in table figure 3, no one has more than 34 hours of work to do, therefore we could assume that the work fits and we can start the sprint.

But in the real world we know this is not true. We have vacation, illness, production issues, training, company meetings, and so forth. In sprint planning we do not pretend these issues do not exist, we bring them into the availability equation. Figure 4 shows the true availability for our team in the week targeted for the sprint.

Click Image to view larger.

Step 5: Compare task estimates to true team member availability

Now if we compare the work needed to the actual time available, we can see if the work fits. See figure 5.

Click Image to view larger.

In our example it looks like Sanjeev’s work should fit within his availability, Keith’s work, loads him up to his capacity, Diane’s work should fit her capacity, and Paul is 9 hours short of the time needed to do his work.

Step 6: Team makes a commitment depending on if the work fits

Once we have the information in figure 5 we would share it with the team and then each team member can say whether the work will fit into their availability. The table is only a tool to help with the decision. A team member can disregard what the table implies. For example, Sanjeev could state that he does not think he can complete all of his work within the sprint, even though the table implies he has capacity. Conversely, Paul can decide to go forward with the work, even though it looks like he is 9 hours overbooked. Paul might explain that there are economies of scale, and some tasks are easier to do if he is already in the code doing work. So he will commit to the work even though the table implies he may be overbooked.

Ultimately, the decision to commit is a team decision, and if the team does not support the workload, we remove stories or tasks until they can commit.

Summary

Many Agile teams do not break their work down to the task level, or review their availability, before they commit to a sprint. By skipping this step they often overload a sprint and end up delivering short. If this becomes a habit, the business and stakeholders will lose faith in the team and their ability to deliver. Take the time to do sprint planning and increase your chances of completing your sprint on time.

Don’t forget to leave your comments below.