Sprint Planning with Jira Using Hours

SprintPlanning.png

I have always found it challenging to do sprint planning in Jira when using hour estimates for user stories. This is because Jira does not have tooling to fully support this need. 

Under this approach, the team enters subtasks for each story that includes estimated hours. The total of these hours is the total work necessary to complete the stories in the sprint. This work is compared to the team’s capacity to see what can fit into the sprint. We use 6 hours per day to calculate capacity. 

In our example, we have a team working on a 2-week sprint. This gives us a capacity of 60 hours per engineer (10 x 6 = 60). 

Table01.png

The above team can fit about 180 hours of work into a sprint. We also are assuming a velocity of 29 story points. Our backlog is shown below.

Table02.png

Jira will support our example so far. The screenshot below shows our pending sprint.

Planning01.png

The work is denoted by the Remaining value of 177, and the story points are denoted by the Estimate value of 27. Given our capacity of 180 and our velocity of 29, these stories fit into the sprint.

Jira does not support capacity planning based on individual engineers or discipline. For example, we cannot see if we have overbooked individual people or our testing and development specialties.
In the past, I have used an extract into a spreadsheet to support this need. This does work, but is cumbersome and slows down the planning process. The SumUp AddOn provides us with a way to do this without spreadsheets.

Sprint Planning Dashboard

Below we see an example of a subtask for the Login Screen. It has an hour estimate of 5 hours, is assigned to Scott Dev1 and has a discipline of Development.

Planning02.png

Subtasks like this have been entered for all of our stories by our team during sprint planning. Let’s take a look at the Sprint Planning Dashboard that was created using SumUp and see if the team is balanced properly.

Planning03.png

We can see our allocation of developers is not proper. We can click on the Scott Dev1 assignee to load the associated data. Let’s assign JSP-17 to Scott Dev2.

Planning04.png

This looks better. Our developers are better allocated. Scott QA is over-allocated, but we have a cross-functional team so one of the developers will help test.

Planning05.png

For teams who do not wish to allocate individuals during sprint planning, we can use Discipline.

Planning06.png

This allocation is OK without any changes. The Testing discipline is over-booked, but our developers will help test. 

Setting Up Sprint Planning

A number of things need to be configured for this example to work. A custom field for Discipline must be added to the screens your Jira project uses. A Filter that returns the subtasks for the next sprint must be developed. 

A Dashboard that is used for planning is added, and the SumUp gadget is configured as shown below.

Planning07.png

In Conclusion

Planning08.png

This does not give us everything other tools provide. We must maintain team capacity outside of the tool and manually compare the Capacity and Work.
Other tools like Microsoft Visual Studio Team Services do this out of the box, as the screenshot on the right shows.

SumUp and this configuration gets us close. It is much better than spreadsheet extracts. I hope this makes your sprint planning easier.