Sprint Planning Checklist: How to Manage

Sprint planning is an event where lots of things can go wrong. From giving the reign to the project owner to wasting the whole day on a meeting that leads nowhere, sprints are tricky to plan properly.

Planning a sprint is not just about coming together and discussing all you have to do. It’s a complex process that involves many parties. You have to prepare for it to ensure success.

If your team shifts tasks to the next sprint constantly, you may need this article to freshen up on the planning side of things. Here’s how you plan for a successful sprint planning meeting.

 

You can use this list for your own sprint planning checklist:

Analyze the previous sprint

All good work starts with analyzing your previous work. This allows you to make your sprints much more effective, and your team more productive. Here are the questions you have to ask yourself.

Did all backlog items got finished?

If you weren’t planning sprints well enough before, the odds are some items were not finished. If you have these, you need to consider them.

First off, you still have to finish them. Assess the tasks, and find the reason they were not finished. Was it because your team was not working well enough, or did you not break the task into small enough pieces for them to cope?

Is it not finished because you assigned the task to the wrong person or because it was dependant on the other task that is not finished yet? Answer these questions, and bring them up individually or on the meeting.

How many issues do you have?

• Analyze how many mistakes and bugs did your previous sprint end up with. If there's a recurrent mistake, you have to address it, or the team’s productivity will never increase.
  
  
• Did some tasks not get finished properly because you gave bad specifications? Did the tasks get done, but not all the team agrees on what the definition of the word “done” is?
  
  

This, and the time your team dedicated to fixing bugs, meetings, and other stuff that is not work should give you a bigger picture of what’s going on.

What was your team’s velocity?

There are many tools that help you measure your team’s velocity, and if you’re not using them yet, you’d better start right now. Even if you don’t use a tool, you can tell that a team’s velocity is lower than expected if it underperforms.

Some teams will work at vastly different speeds. Some teams will show different velocity on different projects. The key to success is giving a team exactly the amount of work they can handle in a sprint.

Update the context

It’s easy to get lost in the endless stream of fixing bugs and adding new features. But this makes you forget about the ultimate goal of a project, satisfied customers.

If you want to reach this goal, you have to know the context.

Update user stories

• Are your user stories written well? If they are, you have to update them regularly. Keep your user stories up to date, and bring in new ones if you need to press on with the product backlog.
  
  

Bring up new tasks

No project can be contained with fixing new bugs. You need to press on with new features. This is why you have to take a look at the product features the project owner will want to implement next and work with them.

• Consider the user stories that describe features the owner wants to get in the language your team understands. Work on specifications drafts, find key tasks and estimate the time your team needs to finish them.

Talk to key people

As a mediator between the client and the software development team, you know the only two sides you have to talk to. Here’s what to talk to them about before you hold the meeting.

Update the owner

Contact the owner to report on the progress made during the previous sprint, and the issues you face.

• Ask about their priorities in the tasks for the next sprint. This is what you have to take to the team next.
  
  

Talk to the team

• Present the team with the tasks and ask them to come to the meeting with estimates. This allows your meetings to run much better and faster.
  
  
• Make sure everyone is informed about the time of the meeting and is comfortable with showing up on time.

Hold the meeting

Some people say the more meetings, the better. This Forbes expert even suggests keeping people engaged every day keeps productivity high.

This may work for some teams, but many people will think that you don’t trust them enough and micromanage them. Checking the progress and wasting half an hour for a daily meeting are very different things.

You should apply the same time-saving approach to sprint planning meetings as well. This is why actually holding the meeting is the last point in the checklist.

Gather all the information you need beforehand so you can minimize the time everyone spends on the meeting, and maximize the time they spend on the project.

Here’s what you should discuss:

The What

• Deciding what to do during the next sprint is not an easy solution. The owner wants as much as possible. The teams differ in their approach. Some teams would protest, some would agree on any number of tasks just to get over with a boring meeting.
  
  
• This is why you, as a mediator, should keep the differences between the team and the owner of the project at the lowest level possible, and get both parties to agree on tasks fast.
  
  
• Prioritize tasks that need to be done the fastest. Keep them on the top of the list, and ask your team to get them done as soon as possible.
  
  
• Break down each user story into a series of tasks. Ideally, you must have done this already, you just need the team to contribute to your ideas and agree on the set of tasks for the sprint.
  
  
• Ask your team to estimate the time they need to complete each task. You may need to add about a quarter to that number if the team was not performing well recently.
  
  

The How

Once you have the set of tasks you have to complete during the next sprint, you need to decide how are you going to do them. Basically, this means answering the question “Who does what when?”

• Make sure all tasks have proper descriptions and are realistic and testable.
  
  
• Distribute story points in whatever way you feel works best. Consult with the whole team to make sure you all agree on how hard each task is.
  
  
• Sort the tasks in time. Place the ones that are prioritized first, and work with the team to detect critical dependencies that can slow development.
  
  
• Appoint individual tasks to people who will perform them best. Give basic tasks to less experienced members of the team, and hard ones to the middle or senior engineers.
  
  
• Agree on acceptance criteria of each task, so that you don’t have to argue about whether the task is completed or not later.
  
  
• Give out testing tasks, if testing is done by in-house employers.
  
  
• Make sure to include bug fixes as something that takes at least a quarter of all the working hours.
  
  
• Start working.

 

Learn from your mistakes

No sprint planning will go as well as you wish the first time. You have to monitor the things that you and your team are doing wrong to in order to correct them in the next planning event.

 

---

 

About the Author: