agile top banner

Leap before you jump, Prepare before you plan!!

Read it in 6 Mins

Last updated on
08th Jun, 2022
Published
11th Jun, 2017
Views
452
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.

ResourceAllocation %Availability during sprint (days)Number of hours per dayTotal hours available
A209.51.211.4
B509327
C1009.5657
D10010660
E1006636
F338216
Total207.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.

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.

Profile

Rumesh Wijetunge

Chief Innovation Officer - Zaizi Limited, Chief Operating Officer - LearntIn (Pvt) Ltd., Director /

Rumesh is an IT business leader with over 12 years of industry experience as a business analyst and project manager. He is currently the CIO of Zaizi Limited, a UK based data management company heading the operations in Sri Lanka, the COO of LearntIn, a global training institute based in Sri Lanka and is also a lecturer / trainer at multiple private universities on management, IT, business analysis and project management subjects. He is the current president of the IIBA Sri Lanka chapter and is one of the most qualified and sought after trainers in Sri Lanka. Refer his LinkedIn profile for more details and to see more articles he has written on linkedin