Sprint Planning

Sadly, even when user stories are standardized, assigned points and prioritized, you can’t just take a clump and say "We’ll do this lot in the next sprint". Books will be thrown, outraged letters sent to the papers and you’ll be left with a wistful look in your eye for a set method in your sprint planning.

‘Planning helps an organization chart a course for the achievement of its goals… and determining the steps necessary to arrive at the intended destination‘ – Brian Hill

Well, we may have dramatized the reaction a tad, but in reality, sprint planning need only take two calls before your fortnightly sprints; one between software engineering and either your product team or owner, and another internal call within engineering.

With this process you can not only get the sprint planning over and done with, ready to carry out the actual work, but you can eliminate any remaining confusion as to the importance of your tasks and level out a (realistic) workload between all of your developers.

After all, there’s no point in realizing the importance of aspects to your business like customer success, if you then bottleneck your progress with a lack of sprint management (which will fix issues customers are unhappy with).

Before you start, note that the main segments of this template ("Ordering the Backlog" and "Assigning the Backlog") should be carried out within your two calls. Check through them to get an idea of what needs doing, but only check them off when they are discussed live.

All set? Let’s get started!

First up, there’s no point in carrying out the sprint planning process if you don’t record the details of your sprint for future reference. After all, what would happen if you needed to roll your code back to the start of a problem, but lost track of when the issue began?

Record the details of the sprint using the form fields below.

Before you go into the sprint planning call itself, it is wise to quickly check whether your user stories have been groomed. This can be done with even a cursory glance at your project management software‘s backlog.

Record the status of your tickets using the dropdown below.

You should be checking to make sure that your user stories have been assigned points, prioritized (don’t worry yet about the prioritization being correct or not), set in a standardized format and have any necessary labels, due dates, etc.

Once again, this should not take you very long – you will usually be able to tell is your team has used a user story template yet by the language of the card and nothing more. You should be good to go if the story is set out as:

• As a <user identity>, I want <desired feature> in order to <goal>

If this is not the case, you may wish to postpone your sprint planning call or meeting in order for the engineering team to do this; we even have our own user story template to help you get it done quickly and efficiently!

First order of business in the call is to swap information between the product team (or owner) and engineering team. This will provide any important context which will shortly help to organize the tasks in your next sprint.

Talk about issues such as:

• Common complaints among users or team members
• Relevant recent or upcoming events (eg: competitor releases)
• Essentially, anything which could affect the order or priorities of the next sprint

Remember that you do not need to talk about every detail of these events; all you should be doing is highlighting key issues which will affect how you prioritize your user stories for the sprint.

Although this almost goes without saying, in order to plan your next sprint you must create one. This can be done through your project management software, and usually only requires the click of a single button. Remember to record a link to the new sprint in the form field below.

To use JIRA as an example, all you need to do in order to make a fresh sprint is to log in, navigate to your project board, click "Plan" and then "Create Sprint". If using a different program, you will need to adjust your steps accordingly.

One of the easiest ways to organise your user stories during the initial sprint planning call is to focus on the high priority tasks. However, as the stories have only been assessed by the engineering team so far, the product team or owner must again be allowed to give their input.

Take a look at the backlog and examine tasks which have been standardized with a user story template. More often than not these will include bugs and broken features, but the new context from your product team / owner may show these stories in a new light.

For example, although a broken feature may be labelled as high priority, more complaints may have been received about a specific bug which is better documented. In this instance, it is worth considering the bug fix before the broken feature.

You do not have to manually alter the priority of each story (doing so would make the call last hours), but you should bear this new importance structure in mind (or note it down somewhere) whilst moving to the next step of your sprint planning.

You now have all the information required to assign your user stories to the correct sprint. Using input from both the product team / owner and engineering team (along with the new priorities), assign tasks to your new sprint until you do not have any more points to fill.

Primarily consider the points of each story and their priority, but if a sprint becomes a little crowded with issues, the stories’ categories can come into play as well. Remember to only assign a certain number of points per sprint; goal figures are fine, but development teams will not appreciate being worked to the bone for unattainable numbers’ sake.

Move the user stories into your new sprint as you go along, ideally starting with the highest priority tasks before moving on to the lower or less pressing issues.

Once your sprint has been planned and had tasks assigned to it, you have a little room to discuss the possibilities for future sprints. Much like the context-swapping at the beginning of the call, this should not be an in-depth analysis, but instead a short round-up of remaining issues.

If any user stories have not been completed (including any previous backlog) which are still important, suggest that they be put into the next sprint, given there will be enough space to allow it.

It’s time for the final call / meeting of your sprint planning process! This time, the software engineering team should start off by discussing the complexities of each issue, and whether they would be best suited to a particular member of the team.

The main goal of this step is to compare the importance of each task against their complexity, and the specialities of any given member of your team. For example, a particularly complex task would probably be better suited to a more experienced team member, whilst more basic tasks (however important they are) are better for your less experienced members.

You have the tasks to cover in the next sprint, along with their correct priority, complexity and the developers which would suit the tasks. Now you need to actually assign your sprint tasks to your developers.

Although this step is pretty self-explanatory, there are a couple of vital issues to consider when doing this. Namely, they are:

• Which developers are available (eg: a developer could be off sick, or on holiday)
• The number of points assigned to each dev (all should be given the same number of points)
• The ability of any given dev (a rookie should probably not be given the most complex task)

Once you have done this, congratulations! You have just completed your regular sprint planning and are ready to kill it on the development floor. 

Brian Hill – The Importance of Planning in an Organization

Andrea Gigante – Creating an Agile Road Map Using Story Mapping

Venkata Gayatri Krishnamurty Pammi – Agile User Stories

Atlassian Documentation – Creating a Sprint

Alex Cowan – Your Best Agile User Story

Gov.uk – Writing User Stories

Roman Pichler – 10 Tips for Writing Good User Stories

Agile Modeling – User Stories: An Agile Introduction

Mike Cohn – Advantages of the “As a user, I want” User Story Template

Codesqueeze – The Easy Way to Writing Good User Stories

CA Agile Central Help – Write a Great User Story

Git Workflow

User Story Template

Scrum Project Management

Software Deployment

Software Testing Tutorial

Software Debugging Process