How to perform Sprint Planning with Jira – Part 2: Using Story Points, Velocity – Pros and Cons

 

This is Part 2 of the Sprint Planning in Jira series. In the first part, I discussed how to prepare for the session and what topics you need to cover. Now, if you missed out on that article, read it here.  

In Part 1, I did mention there were two ways for a team to figure out what they can achieve within a Sprint, they can either use their Velocity, which is based on their Story Point estimates, or they could use a time based approach. Now, I’m going to focus on how to use the team’s Velocity. But don’t worry, if you still want to know how to use time, I will cover that but it will be in the next article in this series. 

Understanding Story Points and Velocity

Before you decide to use Velocity for your Sprint Planning session, it’s first very important that everybody actually understands how it works.

Velocity and Story Point values are two terms that come from an approach called Relative Estimation. And if you’re new to it, or if your team is, go check out this blog post. 

 

Figure out the team’s Velocity

The first step will be for us to figure out the team’s Velocity. To calculate Velocity in Jira, you’ll need to have run a few Sprints. And the Product Backlog items within those Sprints need to have Story Points associated with them. 

If you don’t know how to associate Story Points to Product Backlog items, go check out our video on getting your Product Backlog in Jira right. 

 

Calculating Velocity in Jira

So, assuming you’ve run a few Sprints, you can use Jira as a Velocity chart to calculate Velocity. If you haven’t seen it before, you can go over the reports. When you click on that, you’ll notice that the Velocity chart is an option.

 

So clicking on the Velocity chart, you will notice that it shows you a couple of values per Sprint. 

 

 

Values in the Velocity Chart:

• Committed number of points (grey bar) – the amount of work that the team thought they could achieve in that Sprint.
• Completed number of points (green bar) – the actual number of points that the team achieved.

The completed number of points is what we want to use to calculate Velocity for usage in Sprint Planning. What I like to do is keep it simple. And I take the average of the last three Sprints. So you can see here in the image above that in Sprint 3 the team managed to get through 21 points, in Sprint 4 they achieved 18 points, and Sprint 5, 26 points. 

So to calculate Velocity, we just take the average of those three values as you can see below.

Calculating a teams average Velocity

 

If you would like a more advanced approach to calculating Velocity, then go check out Mike Cohen’s Velocity range calculator. 

Velocity Considerations

There are a few points that you want to keep in mind. 

• The more Sprint’s the team does, the more reliable that metric will be.
• To make sure your Velocity metric is reliable, you will need to keep two variables consistent – The teams Sprint length, and the members of the team.

 

Sprint length – If your team is in the habit of chopping and changing their Sprint length, than what’s going to happen is your Velocity will go up and down and it will be unreliable. However, in the early days of your Scrum implementation it’s okay to experiment with Sprint lengths. But once you decide on what works for you and your team then stick to it. 

Stable team – If your team is being changed each Sprint, in other words, if you’ve got new people joining the team, or people being replaced over and over again, that will also impact your Velocity and make it very unreliable.

Finally, you may want to consider if anyone is going to be perhaps on leave that Sprint and reduce the points accordingly. 

 

Determining the Sprint Plan

Now that we’ve calculated Velocity, we have an idea of the capacity of the team and what they can fit into the Sprint. So to determine what they’re going to get done in the Sprint, we head back over to the Product Backlog view. 

The way I like to run a Sprint Planning session is actually divided into two parts. And the difference between the two parts is who gets involved and what we discuss. So the first part is where we don’t just have the Scrum Master and the delivery team there, but also the Product Owner. 

 

The first part of Sprint Planning is to ask the Product Owner any final questions to clarify the top priorities. The number of items the team discusses depends on their calculated Velocity. For example, if the average Velocity is 22, then we’ll probably discuss enough items to get the team to that workload.

So, what’s the second part of Sprint Planning? This is where we’re going to determine what we can get done inside the Sprint. And for this part, we only need the Scrum Master and the delivery team. To determine what we can get done within the Sprint we need to understand how the work is going to get done, discussing each Product Backlog item and really delving into the details. 

So for example, I like teams to work in priority order. So we start from the top of the Product Backlog, we bring it into the Sprint, and we’re going to discuss the User Story to make sure that we’re well prepared for the upcoming Sprint. 

 

 

So there are a few points that you’ll want to discuss about each Product Backlog item. 

Clarify the technical implementation

What’s involved and who’s doing what work. You’ll be working with a cross functional team in Scrum including people with different skill sets contributing to the Product Backlog item in different ways. So make sure you capture details of the technical implementation inside the Product Backlog item. 

 

Consider dependencies

There’s going to be many types of dependencies, such as integrating with a third party API or another system, or possibly other people such as subject matter experts from another team to support them in this implementation. So consider the dependencies that the team has and make sure that it’s been captured in the user story as well. 

 

Discuss any risks, things to look out for

It may be that the team is working with a new technology, and there’s inherent risk as the team doesn’t know what may be involved in the implementation. Or it may be a team member is away that Sprint and because they’re not around, there’s going to be a level of risk. 

If you think about those risks in advance and you bring it up with the team you’re more likely to achieve a successful plan. Capture the risks on your Product Backlog item, either in the description, comments, or as an attachment.

 

 

After you’ve gone through those points we move onto the next Product Backlog item and follow the process again until we reach the team’s calculated Velocity. To see if you’ve reach your teams Velocity you can see the number of points added to the Sprint in the bottom right corner of the Sprint section (on the Product Backlog view). 

 

 

In my example above you can see that we’ve got one extra point. I.e. we’ve added 21 points to the Sprint, but we have a Velocity of 22. There’s a few things you can do at this stage, you might be tempted to go and bring in the next item. For example, the next item has only three points and it’s going to exceed our Velocity i.e. 24 points in total. But we can only really get 22 done. I tend not to encourage a team exceed their calculated Velocity.

A lot of teams like to use what’s called stretch goals. And they’ll say “Hey Product Owner, if we can, we’ll try and get that one in. But if we don’t have enough time, we’re not going to do it. ” I don’t recommend stretch goals, because in the end, what tends to happen is people expect those items to actually get done and they don’t get done. And then Product Owners and stakeholders feel like expectations have not been met.

So instead of dragging in another item and exceeding your Velocity limit, what I like to do is either ask the Product Owner if there’s a lower priority that can fit in. I.e. in the case above, is there a 1 pointer from lower in the Product Backlog that we could bring into the Sprint. Or we could not pull in another item, and just leave the extra capacity and use it on a number of activities such as those listed below.

 

• Pay down technical debt, most software teams have technical debt, and they wish they had time to pay it down by refactoring and cleaning up code. 
• Work on some process improvements, such a researching / implementing test automation.
• Spend the time refining Product Backlog refinement, looking ahead and saying hey, do we need more details? 
• Schedule what’s called an Innovation Day (if there’s enough spare capacity), allowing a team to build whatever they want for an entire day. 

So, don’t necessarily just try to fill it up to the team’s capacity.

At the end of the session, take a step back and perform a final review of the Sprint plan. Asking the team if they feel it’s realistic, making sure they have considered the sequencing, and whether the work looks like it can actually get done. And then you’re ready, you can hit that “Start Sprint” button. 

 

Pros and Cons of this Approach

Pros

• Quicker – the Sprint Planning session will be shorter, and you can use the additional time for other things. 
• Comfort within the team – you’ll find that some team members tend to feel more comfortable. I’ve met many people out there who feel very uncomfortable trying to come up with a Sprint plan in terms of time, sometimes it can be perceived as micro managing.

Cons

• Requires a few Sprints – You’ll find that you’re going to need the team to run a few Sprints before your Velocity is reliable. In the early days, the Velocity will fluctuate and a reliable Sprint Plan may not be possible. So you’re going to need to wait for usually at least three to four Sprints before you get a reasonable Velocity to use. 
• Not precise – Story Points are not as precise as time based estimation. So for example, if you have a less experienced developer on your team, and a more experienced developer, the less experienced developer is obviously going to take more time to get the work done. However, when you use Story Points at Sprint Planning, that often isn’t evident. So sometimes it means that the team’s Sprint plan isn’t as precise as it could be.
• Harder to understand – Using Story Points, it can be a hard approach to understand and there’s a level of risk that people out there misunderstand how to apply it correctly. It can also be confusing for your stakeholders.