Sprint Kickoff


The Sprint Kickoff is at the start of every Sprint Cycle. Its aim is to set out the priorities of what should be delivered within the length of the upcoming sprint (we will assume this is the next 10 working days, a sprint is typically 1-4 weeks long.).

At the end of the Sprint Kickoff, the team should have a well defined and achievable set of tasks to work on, and the Agile Project Manager should be able to report on the progress of the project (or programme of work).

The Sprint Kickoff meeting should consist of preparation, and the three following talking points.

The meeting itself should take no more than 30-45 minutes, it should contain 4-5 people (to keep it manageable) and most importantly of all, it should be kept on-topic by the chair.

The conversation during the meeting should not become technical, and if an task needs technical discussion, or if the size of the task cannot be agreed upon, it may be added to the Sprint Backlog as a ‘Spike’ for further discussion and clarification.

A spike will have story points assigned to it that reflect the conversation and research needed to define the task, this will then output one or more corresponding tasks.

Before Sprint Kickoff

In this guide I am making the assumption that you are using a Kanban board to manage your project, with the following columns:

  • New Items
  • Backlog
  • Sprint Backlog
  • In Progress
  • Code Review
  • Ready to Deploy
  • Done

If you do not have a Kanban board, you could use labels, or columns in a spreadsheet, or any tool that works with your setup. However, I have found that creating a well managed Kanban board is a game changer.

Depending on the size of your organisation, you may have a Kanban board per project, or one which covers multiple projects.

Each sprint will be treated as a blank slate, so clear off everything that remains in the ‘Sprint Backlog’, and ‘In Progress’ columns.

If everything has been running well in your Sprint Cycle, tasks in the backlog will already be prioritised and have story points assigned to them through the Daily Standup and Sprint Retrospective.

During the Sprint Kickoff Meeting

Setting Sprint Focus

Depending on the size of your organisation, you may have one project for your team, or you may be a smaller organisation balancing multiple projects between one team.

The first item on the agenda is to take a look at all the tasks that are in the backlog and decide what the main priority (or priorities) of the sprint will be.

If you are a team looking after one project, this will be key functionality that needs delivering in the upcoming sprint. If you are balancing multiple project then this will be which projects need the most attention in the upcoming sprint.

Prioritising Tasks

As I mentioned previously, the priorities and story points of each task should already be known, however if there are any that have been missed, now is the time to apply those estimates and story points.

It is worth noting that when you assign priorities, you should do it with the upcoming sprint in mind. Ie ask yourself ‘How important is it that this is delivered within the next sprint?’.

Before we can add tasks to the backlog, we need to know how much time there is available within the sprint. A quick round-table of any planned leave at this point is a good idea, to give us a rough estimate of how much time we will have in the sprint.

With the amount of time available in the sprint roughly known, we can equate this to story points available for us to ‘spend’ on the sprint.

Assigning Tasks to the Sprint Backlog

Now that we know our priorities, we simply need to start dragging the highest priority tasks across into the sprint (if we are using a Kanban board).

As we do this, we also make notes of the story points that are attached to each of the tasks, and making sure that we do not exceed the amount of story points available within the sprint.

You should try to avoid assigning tasks to individual members of the team, instead allowing the team to manage their own workload during the sprint (after all an Agile team is self organising).

At the end of this process you should have a packed sprint backlog that has tasks with a total amount of story points do not exceed the available story points for the sprint. The tasks in the sprint should be ordered by priority and they should be well defined.

The team should now be about to start working on the tasks, which will be reviewed again during a sprint refinement and finally reviewed in the sprint retrospective.