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

Are you overloading your sprints?

Are you overloading your 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.

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.

A Big Picture Perspective of the Agile Lifecycle.  Teams often skip sprint planning, which increases the probability of over committing.

A Big Picture Perspective of the Agile Lifecycle. Teams often skip sprint planning, which increases the probability of over committing.

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.

Figure 1 - Based on estimated story point velocity, a release plan shows stories target for sprints.

Figure 1 – Based on estimated story point velocity, a release plan shows stories targeted for sprints.

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

Figure 2 - A team designs and plans each story in detail during sprint planning.

Figure 2 – A team designs and plans each story in detail during sprint planning.

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:

Figure 3 - A team identifies and estimates all of their tasks for a given sprint.

Figure 3 – A team identifies and estimates all of their tasks for a given sprint.

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.

Figure 4 - A team determines their true availability for a sprint.

Figure 4 – A team determines their true availability for a sprint.

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.

Figure 5 - A team compares work estimates to availability to see if the work will fit  into the sprint.

Figure 5 – A team compares work estimates to availability to see if the work will fit into the sprint.

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.

Advertisements
This entry was posted in Agile Practices. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s