So, how do you get a Scrum team to conduct Sprint Planning effectively? There’s typically two ways you can go about it – (1) you could use Velocity and Story Points, or (2) take a time-based approach, and estimate items in days or hours. Which one do you choose? Which one is better? And how do you actually do that in Jira?
Well, what I’m going to provide you with is a series of videos to answer those questions. And this blog post is based on the first video of that series. In this post I’ll cover the following:
An overview of Sprint Planning, what questions you’re trying to answer, what’s the intent behind the session.
Run you through how to prepare for this session, there is a bit of work that needs to be done beforehand, to ensure they run smoothly, and they don’t take too long.
Show you how to set up a Sprint in Jira. So you can make sure that your Sprint Planning session is ready to get started.
Overview of Sprint Planning
Sprint Planning is about answering three topics:
Topics to be covered in the Sprint Planning session
Why is this Sprint valuable?
What will actually get done this Sprint?
How will that work get done?
It’s really about answering those three things. And just because I mentioned those questions in that order doesn’t necessarily mean you actually have to answer them in that order when your Sprint Planning session is running.
We may only figure out the answer to the three topics by the end of the Sprint Planning session, or sometimes it’s a different sequence. It will be up to you and your team. But I’ll show you how I typically run one of these sessions.
Preparing for Sprint Planning
Before we begin Sprint Planning, there are a couple of things you need to make sure has been prepared.
Before Sprint Planning, make sure you come prepared with adequately refined Product Backlog Items and the team’s capacity determined.
1. Adequately refined Product Backlog items
Product Backlog items first need to be prioritised and secondly, have a sufficient level of detail that the team knows what they need to do. Now, if you don’t have these types of items, you’re going to have very painful, long-winded Sprint Planning sessions. And why, in the end, the team does more than just planning at this session. They start eliciting requirements, they’re figuring out details. And in the worst case, they don’t have the right people on hand to clarify what needs to get done like subject matter experts, or stakeholders.
Product Backlog Items brought into Sprint Planning should be ‘Sprint-ready’
If the team doesn’t have clarity over the requirements, then what’s going to happen is the team either can’t deliver that work or they attempt to deliver it with very ambiguous requirements. And of course, that’s very risky, the team might deliver the wrong thing and then have to rework it. This in turn leads to unhappy stakeholders.
The trick here is to make sure that before Sprint Planning, those Product Backlog items have been refined sufficiently, and they’re what we call ‘Sprint-ready’. ‘Sprint-ready’ Product Backlog items should be:
well defined
well understood
they are of the right size
2. Team Capacity Determined
Next, we need to make sure our team has figured out their capacity. In other words, they need to determine what they can actually get done within a Sprint. And to determine that they need to know either how much time they have at hand, or they need to know and understand their workload, what can they take on in that upcoming Sprint cycle.
To determine the team’s capacity will depend on the approach that they take. If using Story Points they’ll use their average Velocity, or if they’re using time they will need to calculate how much time each person has.
In summary, before Sprint Planning, we need to have two things prepared, our Product Backlog items sufficiently refined, and secondly, the team’s capacity, so we know what they can bring into the Sprint.
How to Set Up a Sprint
Now let’s look at how we can set up a Sprint in Jira. This is something that you’ll do at the beginning of your Sprint Planning session. And ideally, make sure the entire scrum team is there. So Scrum Master, Product Owner and the delivery team. I do like Product Owners to be here at this stage to answer questions to support the team. They can leave later in the Sprint Planning session.
Include the whole Scrum team at Sprint Planning, at least at the beginning
1. Make sure that you’re on the Product Backlog view
You can just click on it on the left here. And don’t forget that we are using a company managed project with the scrum template.
A Sprint can be created from the Product Backlog View in Jira
2. Click “Create Sprint” button
Once you’re on the Product Backlog view, you will notice that there is a ‘Create sprint’ button. Just click that. And you’ll notice that a section above the Product Backlog will appear for the Sprint.
Jira will create a section for your Sprint above the Product Backlog
3. Add details
What we want to do here is to set some details. So you can either click the “Add dates” link under the Sprint name, or you can go up to the three dots to the right and click “Edit sprint”.
Update the details of your Sprint by clicking on the ‘Add dates’ link to the left or the elipsis button to the right
Sprint name
Firstly, you can give it a Sprint name. If you like just leave it as it is, Jira will automatically increment that number, for example Sprint 1, Sprint 2, Sprint 3 and so on.
Update the Sprint name, start/end dates, and Sprint goal
Alternatively I’ve met teams where they would add modify the Sprint name, indicating the focus of the Sprint. For example, the team might be focusing on a certain goal, feature or non-functional requirement like performance and scalability. What you’ll find is that if you add that to the Sprint name then when you go back looking at the reports it can remind you of what the team was working on which can be useful.
Some teams do like to add themes to their Sprint names. Now, this is just a bit of fun. You don’t necessarily need to do it. But I have seen teams where they name their Sprints after characters or philosophers. Perhaps based on what your team is interested in, it can be a bit of fun and make the session a little bit more lighthearted.
Give your Sprint names a theme to add some fun to your Scrum process
Sprint length
Next, you’ll need to decide on the length of your Sprint. So hopefully you’ve decided on this beforehand with the team. Most typical Sprint length is two weeks. A lot of people ask me what length of Sprint is best.
There’s no right and wrong answer but two weeks seems to be the best choice for most teams based on what I’ve seen out there. Some teams like to go a little bit longer, three weeks gives them a little bit more momentum. Some other teams like to go for shorter Sprints. They just go for the one week Sprint and that’s because their requirements are very volatile. They find that after one week, their requirements have changed already. So for them two weeks doesn’t really make sense.
Choose a Sprint length that is appropriate for your teams context
I don’t usually see many teams go for a four week Sprint anymore. If you’re thinking of doing that just be careful because the longer your Sprint is the longer it is before you engage with stakeholders and gain their feedback, slowing down the teams ability to adapt. So, if your team ends up planning the wrong work or doesn’t do the work correctly, then there’s going to be a larger amount of rework in subsequent Sprints.
Sprint goal
Setting the Sprint goal can be useful for the team. Remember, one of the topics that we need to address in Sprint Planning is why is the Sprint valuable. And this is where the Sprint goal comes into it, it helps the team articulate to stakeholders how they are creating value for customers.
For example, in this Sprint, we have a product called 1 on 1 Car Rentals. Let’s imagine the goal is to allow customers to sign up and show interest. So, we put that in the Sprint goal field. And like I said earlier, you can either add the Sprint goal at the beginning of Sprint Planning or you can leave it blank, and come back to it at the end of the session after your team has figured out what they can get done.
4. Click update and save the Sprint details
After you click update and save the Sprint details the dates and Sprint goal will appear under the Sprint name. They will also appear in the Sprint view after you start the Sprint, and lastly, you’ll notice that the Sprint goal will also appear on the Sprint report which you’ll generate at the end of the Sprint (more on later in another video).
Details of the Sprint can be seen below the Sprint name, on the ‘Active sprints’ board, and on the Sprint report
So there you have it! That is how we set up a Sprint in Jira 🙂
Have some creative Sprint names to share?
I’d love to hear if you’ve heard any funny or creative Sprint names. I’ve heard all sorts of things, from characters to sports to movies. A little thing like a funny Sprint name can actually elevate the mood of the team, make them more productive and happier in the workplace.
I’d love to hear what you have heard out there. So if you’ve heard any funny Sprint names, please put them in the comments below.
What’s next?
In the next article, I’ll take you through the next step of Sprint Planning and determining what we can actually get done within the Sprint.
If you don’t want to miss out, please make sure you subscribe to our Youtube Channel, hit that bell icon to be notified of new content we publish – plenty more to come!
