Manage Learn to apply best practices and optimize your operations.

Estimates in Agile development: Capacity matters in sprint planning

When doing sprint planning, how do your team members know they have enough work assigned to them in the sprint? Figuring out the hours you have available before you start planning is the best way to start. Author and Agile coach Steffan Surdek explains how teams can calculate their sprint capacity to help them improve their commitments.

The biggest challenge many teams new to Scrum face is to understand when they are over-committing themselves during...

the sprint planning meeting. Before doing any sprint planning, the first thing teams should do is identify their sprint capacity, which is the number of hours they are available to work on backlog items during the sprint.

The starting point all teams should use is the total number of hours available in the sprint. This value is the number of weekly working hours multiplied by the number of weeks in the sprint. For this article, we will use a fictional team working 40 hours a week and using a three-week sprint. This gives them a baseline of 120 available hours.

Teams need to consider the following information when identifying their capacity:

  • Scrum ceremonies
  • Training days, vacations and statutory holidays
  • Recurring meetings
  • Effective time on task
  • Creating backlog items instead of reducing capacity

Scrum ceremonies

The various ceremonies in Scrum take time away from the team. A good practice is calculating the total time needed for all ceremonies and subtract it from the available time for the sprint. Assuming the planning meeting for our fictional team lasts four hours, a review meeting lasting two hours and a one-hour retrospective. This totals seven fewer hours available for the team to work.

The next meeting to consider is the daily scrum meeting. Take 15 minutes and multiply by the number of days the meeting occurs in the sprint (some teams do not hold a daily scrum on the first and last day of a sprint). For a three-week sprint, this is nearly five hours fewer the team is available. 

Some teams absorb the daily scrum meeting in their buffer time and do not remove it from their capacity. This is a team decision and is fine as long as the meeting lasts 15 minutes. For teams where the meeting regularly lasts longer, they need to find ways to stick to the time box and make the meeting more effective for everyone.

Some teams also do backlog maintenance sessions to groom and prepare their backlog. If your team does this, you need to remove that time as well.

Training, vacations and statutory holidays

This information is something team members can easily predict at the start of the sprint planning meeting. 

Recurring meetings

Considering recurrent meetings when calculating capacity is important because it raises their visibility for the team. To show why this is important, we will use a one-hour committee meeting attended by two team members as an example. The cost of attending this meeting is two hours if this meeting happens once in a four-week sprint, but this number quadruples to eight hours when the same meeting occurs weekly. 

Considering recurrent meetings when calculating capacity is important because it raises their visibility for the team. To show why this is important, we will use a one-hour committee meeting attended by two team members as an example. The cost of attending this meeting is two hours if this meeting happens once in a four-week sprint, but this number quadruples to eight hours when the same meeting occurs weekly. 

I strongly believe that time is money and the time spent in a meeting must give a return on investment to the team. When the return is low, the team must question why they attend it and consider the alternatives shown in table 1. 

Effective time on task

Some teams apply an “effective time on task” factor to their total available hours in the sprint. This factor helps team members compensate for e-mail, nature calls, coffee breaks and those impromptu hallway conversations. This value can also vary from 0.7 for teams experienced with Agile practices to 0.5% for teams or members beginning their Agile journey. Using a lower value for people new to Agile provides a buffer to allow team members to get comfortable using Agile practices and reduce their risk of over-committing.

Because the effective time on task factor reduces the available number of hours in the sprint, it allows team members to absorb some of the time needed by shorter meetings. You should use judgment and common sense to decide if it is work removing daily scrums or a weekly one-on-one meeting from your capacity. 

Creating backlog items instead of reducing capacity

Sometimes, instead of reducing your capacity, you may want to add a backlog item or task to the product backlog to give it visibility. For example, in my current job, I give training sessions. When my team builds their sprint plan, I have a user story to deliver the training in which I create tasks for anything related to the training session. These tasks will cover the time needed to review the material or to prepare materials. I also have a task to cover the time I am giving the training.

Using a backlog item is also useful for teams that need to do support tasks during their sprint. These teams can create a generic support item in their sprint and create tasks with a fixed number of hours each member can spend working on support issues.

Having such information in the sprint plan helps others on your team see where you will spend your time. It also helps you have a regular capacity from sprint to sprint instead of burying time you are spending doing valuable work.

How to calculate capacity

Figure 1 shows a formula teams can use to calculate their capacity. This method considers all the variables explained earlier and provides an estimate of the available hours in the sprint for each team member. It takes the total hours of the sprint and subtracts the hours for ceremonies, vacation, training, meetings and others. After doing that, it applies an effective time on task percentage to factor in real-life interruptions.

Figure 1 – Formula to calculate sprint capacity

Conclusion

Team members should consider the time needed for sprint ceremonies, training, vacation, statutory holidays and recurring meetings when calculating their capacity. Team members should remember their capacity is just an estimate and not an exact science. 

The effective time on task factor reduces the number of hours team members work in a day. A 0.7 factor applied to a normal eight-hour work day turns it into a five and a half hour work day. Before removing time from their capacity for a recurring meeting, team members should consider if they can absorb that time as part of the buffer provided by the effective time on task factor.

Creating a new backlog item and assigning tasks with hours instead of reducing capacity allows team members to give show where they are putting their work efforts without continually changing their capacity from sprint to sprint.

Calculating capacity can help a team and its members to make sure they are making the right commitment for a sprint assuming their task hour estimates are correct. Team members may sometimes have more hours planned in the sprint than their available capacity and still be comfortable they will meet their sprint commitments.

This was last published in June 2011

Dig Deeper on Agile Software Development (Agile, Scrum, Extreme)

PRO+

Content

Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close