Get certified - Transform your world of work today


Prepare Before You Plan!

Sprint planning preparation

11 February 2016

Rumesh Wijetunge
Zaizi Asia

An issue with most IT project teams is that they jump into solution implementation without proper planning. It is no different with most Agile/Scrum teams. I would like to discuss an important responsibility of a ScrumMaster and a best practice to ensure that proper planning is done.

Before going in to a sprint planning meeting, the ScrumMaster must talk to each member of the team to identify the amount of effective time he or she will be available during the duration of the sprint. A sprint may run for, ideally, two, three, or a maximum of four weeks. Let’s assume our project has an agreed sprint duration of two weeks. The following are important points to consider before going into the planning meeting:
  1. The team must have agreed on the number of effective hours of effort it will commit to per day in order to carry out project work. Note that a team member may be involved in extra activities in office, not to mention needing time for lunch, tea, and washroom breaks and other personal tasks, which must be considered when calculating the given time period.
  2. The ScrumMaster must identify the number of holidays during the two-week time period.
  3. The ScrumMaster must identify the allocation percentage of each team member.
  4. The ScrumMaster must inquire about the number of planned days of leave each team member willbhave during the course of the sprint.
So, let’s do some simple math. Details about three team members are as follows. For simplicity, let’s assume there are no holidays during the course of the sprint (two weeks, 10 weekdays) and that team members have agreed to work for six hours per day on project work.
  • Team Member A (UI/UX engineer)
    • Fifty percent allocation (three hours of effective time for the project per day)
    • One day of planned leaves
  • Team Member B (developer)
    • One hundred percent allocation (six hours of effective time for the project per day)
    • One half-day of planned leave
  • Team Member C (QA engineer)
    • One hundred percent allocation (six hours of effective time for the project per day)
    • No planned leave
So, what is the capacity of the team for the sprint? I maintain a table similar to the following for my team and update it before the sprint planning meeting.
Resource Availability (Days) Allocation (% of effective hours per day) Capacity (hrs)
A 9 50% x 6 9 x 3 = 27
B 9.5 100% x 6 9.5 x 6 = 57
C 10 100% x 6 10 x 6 = 60
    Total Team Capacity 144
Why is this important? When I go into the sprint planning meeting, I know how much my team’s capacity for the sprint is, as well as how much each team member is available during the sprint. It helps me, as the ScrumMaster, in negotiating with my product owner to take the proper amount of tasks for the sprint. For example, during sprint planning we break down stories, adding tasks to achieve the objectives of the story and assigning hours for each task. If Story A takes 35 hours, Story B takes 52, and Story C another 50, I know that we have reached the maximum amount of tasks that I can take for the sprint, since those 3 stories temselves take 137 hours to complete roughly, and the team capacity is 144 hours.

Similarly, proper planning would mean that Team Member A, the UI engineer, can take tasks that take less than or equal to 27 hours, Team Member B less than or equal to 57 hours, and so on.

So, prepare a similar table before going into your planning meeting. As the ScrumMaster and team, together you actually can justify to your product owner that this is the maximum amount of tasks you can take up for the sprint. It will create more visibility, the team will feel more responsible, and they will work cohesively to achieve sprint objectives.

How do you carry out your planning? I would really like to hear from you.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.7 (3 ratings)


Niroshan Madampitige, CSP,CSM, 2/11/2016 8:24:59 AM
Good stuff Rumesh. It's also useful, if the scrum team works on product backlog grooming, identifying the stake holders, and grouping the requirements into problem areas or feature domains so that your planning is effective. . Also, keeping a small buffer for handing unexpected changes, tasks, and priorities would be a good practice to ensure you don’t over-commit. Also, Mike Cohn emphases that you should separate estimates form commitments – which means, from your estimates, you must decide what exactly your commitments considering risks, dependencies etc… Happy to discuss more. Anyway, I appreciate your insights…
Karl Barthel, CSM, 2/12/2016 8:12:45 AM
Great way to micro manage your team! This isn't Scrum, this is command and control waterfall thinking. Let the team manage how much work to bring in; as a Scrum Master your job is to coach and guide them in the discussions, not organize them.
Rumesh Wijetunge, CSP,CSM,CSPO, 2/16/2016 6:45:53 PM
Karl, it's not not at all micro management. It's capacity planning with which you indicate to the client this is the only amount of work the team will take up for the Sprint. Scrum master won't dictate the amount of work. He just guides the team in deciding how my they can do.
Rumesh Wijetunge, CSP,CSM,CSPO, 2/16/2016 6:48:06 PM
Thanks Niroshan. Yes, you do keep a buffer by not over committing than the team capacity.
Rumesh Wijetunge, CSP,CSM,CSPO, 2/16/2016 6:48:56 PM
Thanks Niroshan. Yes, you do keep a buffer by not over committing than the team capacity.
Rumesh Wijetunge, CSP,CSM,CSPO, 2/16/2016 9:07:29 PM
Thanks Niroshan. Yes, you do keep a buffer by not over committing than the team capacity.
Tim Baffa, CSM, 2/22/2016 10:52:08 AM
Agree Rumesh that capacity estimation is not micro-managing, but I can see where comparing an individual's capacity estimate to task estimates can reflect that.

I personally consider it wasteful to have teams spend any effort providing time estimations for either stories or tasks.

I do like to follow a similar capacity estimation exercise, but only to identify the total team capacity in hours. The "total team hour" metric provides the team with another perspective on team capacity outside of velocity/story points.

Sprint story acceptance should still be based on the relative estimates provided by the team (story points) as compared to team velocity (or what the team feels comfortable in accepting).

For example, say a team has a velocity of 100, and they typically have an average team hour capacity of 300. If they calculate 250 hours for the upcoming sprint (due to time off, meetings, training, etc), they should consider accepting less than 100 story points for the upcoming sprint.

As always though, the decision should solely be left up to the team regarding the amount of stories / story points to accept.
Rumesh Wijetunge, CSP,CSM,CSPO, 2/29/2016 12:09:19 AM
Thanks for your feedback Tim. Much appreciated. Its really good to discuss how different teams from around the world practice Scrum and how they've adapted the core building blocks of Agile :-). Yes, my objective is just team capacity planning from an hour perspective (since we will anyway be burning hours during the Sprint) and not at all to micromanage. I believe Agile is about creating visibility and transparency and planning is a sure way of ensuring this from the initial stages itself.
Chandrasekaran Janakiraman, CSM, 5/3/2016 6:01:10 AM
Good article. Most of the ALM tools like CA Central Rally support Iteration planning by calculating whether Team capacity can support commitments for the BPO prioritized User stories. This provides the team during planning to re-assess their commitments. In my experience, we have had iterations where team had made innovative approaches to meet commitments when constrained with capacity that then became best practices for other teams to follow! There were also iterations where BPO was able to scale down the velocity based on what the team felt. We had reduced capacity for an iteration to support a team building event :-) I personally think this aids the team to have ownership of the work they do and builds the trust with everyone (BPO, Scrum master and team)

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up