Sprint planning

What is it? #

Sprint planning meetings take place at the start of every sprint. They are used by the team to agree what work to deliver for that given sprint.

They are an opportunity to reflect on the project’s goals and roadmap, and to prioritise the most valuable work that pushes the project forward. They should give the team clarity about what they need to focus on and why. They can help build consensus about the direction the team and project are going in. They typically last about an hour.

Who should be invited? #

Sprint planning should involve everyone in the delivery team - this should usually include dxw and the client teams together. This is important as it helps establish a close working team with a shared understanding of what’s important.

Preparation #

A well run sprint planning session takes some preparation. Investing the time up front will help your team be clear on what they need to focus on.

• Think about the priorities for the sprint. Review your project’s goals and roadmap - what is the most important thing you need to do?
• Speak to members of the team. Get input from the product manager, the tech lead and others to get their thoughts on what’s important.
• Clean up the backlog. Update tickets from the previous sprint as best as you can, and make sure things are in the right columns. Make it clear what the priority tickets are for this sprint, for example by putting them to the top of your backlog.

During the meeting #

Have a facilitator for the meeting - usually the product manager or delivery lead. As a team:

• Review the project board from right to left, to see what’s been shipped in the last sprint and to see what’s still in progress

• Review the backlog in priority order (i.e. top to bottom). For each ticket go through the title and description.

  • If the ticket isn’t clear then reword it so that everyone understands what’s required.
  • Assign it to a person or discipline in the team
• Break down bigger tickets into smaller ones if needed
• Identify dependencies (dependency label where something is going to be blocked)
• Gauge as team whether the work is realistic and achievable; revisit what you’re committing to until it does.
• Identify opportunities for pairing/ knowledge transfer

Once you have a prioritised set of work for the sprint that the team are happy with, people should refer back to this on a daily basis to pick up work. You can use it in daily standups to track progress. If you get a sense that the scope is creeping or the team doesn’t have the skills or the size you need, then do something to address this.

Project boards and tickets #

We typically use Trello to create project/product roadmaps, as well as sprint boards. Clients occasionally have other similar services in place, such as Jira.

Creating tickets in the right way helps the team be clear on what they need to do. Below are some tips for writing good tickets.

• Have one ‘thing’ per card, and make it the smallest possible thing. This helps create a sense of momentum.
• Identify dependencies - including things that the ticket impacts, as well as things that it will rely on
• Write the ticket in a way that helps someone in the team pick it up and work on it
• Connect the ticket back to a need - e.g. a user need or a project goal. Is it clear why this work is important? How will you know it’s done the job it needs to?

Generally, try to avoid:

• Getting into the weeds on how the ticket will be implemented
• Planning too far ahead - keep the length of the project in mind, but in sprint planning focus primarily on the next fortnight
• Getting into retrospective territory

Last updated: 9 May 2023 (history)