Sprint Planning right from your Backlog screen

blog - capacity planning
From my experience, the sprint planning phase is one of the hardest phases to implement in scrum. Many teams strangle with this phase, and the outcome is often far from accurate (and this is the exact things we will later check in the retrospective meeting). But still, while implementing scrum in companies and reviewing different teams, I’ve seen some teams that actually made this phase relatively easier.
But, what are the challenges we are dealing with in the sprint planning phase, and what can we do in JIRA to tackle these challenges.
The challenges that I hear the most are these:
  •       How can I select my PBI’s and how can I see if they fit in my sprint?
  •       How do I distribute my work to a sprint?
  •       How can I check my capacity?

The sprint planning begins with Product owner indicating the priorities for the Product Backlog Items (PBIs) so that the team can focus on the relevant PBI for the sprint planning process.


screen of Jira backlog tasks

If there are work debts (PBI that were not finished on the last sprint) we will need to add them as well to the PBI list we are planning to do (actually these are with a higher priority than the new ones) – This can happen because either those items were beyond the capacity of the team, or were having some related impediment or were just not completed in the earlier sprint

As the first activity of the sprint planning, the team will set the potential work days available in the next sprint. This should take under consideration teams holidays, personal vacations, or other personal obligations that will reduce personal availability for the sprint period. In the case of JIRA, that can be done through the a relatively new plugin call “Sprint capacity Planning & Tracking”.

Capacity Planning
In the initial scrum meeting, the team will set the capacity of various team members for this sprint. Moreover, team member may work on multiple projects (sprints) and hence may devote different amount of time for each of them. You can now set the availability time per each member. Assign each team member the days capacity off days or leaves per sprint as shown below. You may as well set the off days for the whole team.

Team Setup screen


When you put the right PBI’s and tasks in to your sprint, it is time for giving them (better) estimation for them. Usually work items are estimated in hours or days. To have a clear view if the number of hours you estimate are still in line with your capacity, you can use the new Sprint Capacity Planning & Tracking plugin planning panel.

By selecting the team in the panel, the capacity panel can be used to list your team resources and their current availability.

By assigning tasks to a person, the bars fill up and you get a great view on your capacity planning.

Capacity Planning panel

Now we will balance the load so that it does not exceed the capacity of the team and team members.

If there are number of team members for whom the load exceeds the capacity. We will go ahead and move the task back to Product Backlog so that the load will reduce and will be within the capacity of the team member. As long as we have enough potential free time for a member we will have a green color bar indication. As we get closer to the maximum limit (90%) the bar color will be changed to yellow. If we will go beyond the calculated capacity of the member (over 100% allocation) the bar color will be changed to red.

When all team members are set with tasks, and their capacity is fitting the potential work time set for the sprint (better to keep some reserve – I recommend to plan no more than 90% of the potential time) we would have a plan that the team can commit for. Personal and team commitment for the sprint plan is one of the base pillars of the scrum methodology. This allows us to move from “best effort” style into “commitment” style. The commitment is a key factor for the team to make the plan happen and make the needed extra effort in some situation. Such team just might do the change between missing sprint (and releases) deadline to keeping the actual results same as our initial plans.