Leap before you jump, Prepare before you plan!!

The Sprint Planning meeting is an integral part of the ceremonies carried out by a Scrum team. Get it right; it will be more or less smooth sailing during the sprint.

However, an issue with most of the product or project implementation teams is that they jump into solution implementation mode without doing proper planning. Agile teams are no different. Most often it is because of not doing enough preparation before a Sprint Planning meeting. As a result, the sprint planning meetings overrun, become unproductive and just becomes a ritual carried out for the sake of formality.

So, what should happen ideally? May be a bit of capacity planning for the sprint…

Before going into a sprint planning meeting, the Scrum Master must talk to each member in the team to identify the amount of effective time he or she will be available for the duration of the sprint. A sprint may run for ideally two, or for three or a maximum of four weeks based on the agreement between the implementation team and the product owner.

Let’s assume that our project has an agreed sprint duration of two weeks. Following are the important points to consider before going into the planning of the meeting:

Team members must have agreed on the number of effective hours of effort they will commit to per day in order to carry out project work. This may be a factor agreed upon right at the inception of the project between the client and the implementation organizations.

Note that a team member may be involved in extra activities in office, not to mention the time for lunch, tea, and washroom breaks and other personal tasks, which must be considered when calculating the committed number of hours.

For example, though an employee is expected to be in office for 8 hours per day he may spend only 6 hours effectively on project work. Thus the daily capacity for a team member allocated 100% for a single project would be 6 hours.

The Scrum Master must then identify the number of holidays which falls during the sprint duration. These are the public holidays which are given to every employee in the company.

The Scrum Master must identify the percentage of allocation of each team member on the given project. For example a UI engineer will be shared across 2 or 3 projects and may have a partial allocation of 25% for the given project.

The Scrum Master must inquire about the number of planned days of leave each team member will have during the course of the sprint. And the Scrum Master Is The Key To A Team’s Success.

So, now let’s do some math.

Lets assume that there are 4 members in the team and the details 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.

1. Team Member A (Architect)

• 20% allocation (1.2 hours of effective time for the project per day)
• One half-day of planned leave

2)  Team Member B (UI/UX engineer)

• 50% allocation (three hours of effective time for the project per day)
• One day of planned leaves

3) Team Member C (developer)

• 100% allocation (six hours of effective time for the project per day)
• One half-day of planned leave

4) Team Member D (developer)

• 100% allocation (six hours of effective time for the project per day)
• No planned leaves

5) Team Member E (QA engineer)

• 100% allocation (six hours of effective time for the project per day)
• 4 days of external training

6) Team Member F (Business Analyst)

• 33% allocation (2 hours of effective time for the project per day)
• 2 days of 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	Allocation %	Availability during sprint (days)	Number of hours per day	Total hours available
A	20	9.5	1.2	11.4
B	50	9	3	27
C	100	9.5	6	57
D	100	10	6	60
E	100	6	6	36
F	33	8	2	16
Total				207.4

What does this mean? The team’s availability for customer work is approximately 207 hours and the availability of each type of resource has also been identified. For example the team should ideally take up user stories which may require approximately 125 hours of development effort (resource A + C + D).

Why is this important?

When the Scrum Master goes into the sprint planning meeting, he/she knows how much the team’s capacity for the sprint is, as well as how much each team member is available during the sprint. It helps the Scrum Master, to negotiate with the 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 65 hours, Story B takes 82, and Story C another 70, I know that we have reached the maximum amount of tasks that I can take for the sprint, since those 3 stories themselves take 217 hours to complete roughly, and the team capacity is 207 hours.  It also helps to identify and incorporate buffer time for the Sprint, just in case something goes wrong!!

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

Is this Micromanagement?

Some might argue that it is micromanagement. Yes, the scrum team is a self-organizing, self-healing team. But no, this is not an attempt to micromanage the team but an attempt to provide better information to the Scrum Master and to the Product Owner to help them make more informed decisions.

The team must decide on the best way to take the project / work forward and determine the amount of work that they can take up for a particular sprint, based on the team’s velocity which is based on story points. This capacity estimate described above enhances the capability of velocity based task estimation thus helping the team make decisions on even whether to decompose larger user stories further.

PRINCE2 Foundation certification prerequisites are crucial for advancing your understanding of project management principles and techniques. This certification is the ultimate career enhancer! Enroll now to learn more and take the first step towards success.

What the capacity estimation does not infer…

The capacity estimate does not mean that the team should stick to taking up work which they feel would take around the same number of hours as the capacity estimate. It just gives a guideline to the team indicating that you may be able to take up worth this much of effort. The team may select more or lesser number of user stories and if in case tasks remain at the end of the sprint they may just create a new story in the subsequent sprint and add the remaining tasks there.

So finally,

So, prepare a similar table before going into your planning meeting. As the Scrum Master 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.