Meet our sprint planning document

Sprint planning document for sprint 62 Elmo, where it usually sits, in plain view on my desk

Let’s say you have a team of eleven knowledge workers, who have a wide portfolio of responsibilities, and you need to get a bunch of tasks done, across multiple projects, within a two-week window. How would you keep focus on everything that needs to be done?

Here’s one of the tools we’ve developed to help us do it: we call the sprint planning document.

But first, a little background.

As we have no doubt lamented in multiple blog posts, one of the main challenges we face in the digital communications team is the breadth of responsibilities we have.

We are responsible not only for building beautiful websites as part of the external website programme, we have many other (business as usual) commitments, such as

  • support and maintenance calls
  • social media campaigns
  • monthly editorial calendar to ensure the external website is up-to-date
  • update the digital prospectuses each year
  • consultation on other digital-focused projects

There is such a variety here that it’s easy to see how on some days it feels like we’re flitting, like a butterfly, from one thing to another. The question remains: how do we keep focus?


About a year ago (at the end of sprint 14—we are currently galloping through sprint 62) we trialled our first sprint planning document.

This first edition was little more than three pages of A4 with four tables. The tables listed all our projects (project code, name, current stage, project manager, sprint goals and deadlines), portfolio board meeting dates, business as usual goals, and retrospective objectives.

It ended with a short biography and photo of the person after whom the sprint was named; it was the American cyclist and Olympian Bobby Julich, thanks for asking.

The first page of our prototype sprint planning document

It was simple, but it worked. It wasn’t much more than a glorified list but it helped keep our focus. So we iterated on it and began to add more information that we found ourselves repeatedly looking for throughout the sprint.


In sprint 18 we added a calendar to capture significant events during the sprint. In sprint 20, we indicated when team members would be out of the office. By sprint 40 it was in colour, and there were further small tweaks here and there.

From sprint 18 we added a calendar to highlight key events and team member absences

Even now, we’re not done tweaking it—it is still very much a ‘living’ document that adapts to our ever-changing requirements. Over the past year we have continued to iterate and improve it.

Quite often you’ll hear someone in the team say, “Oh, you know what would be really useful to include on the sprint planning document?” And usually they are right.

The document now stretches to nine pages. But it doesn’t feel overly long because it contains the right information.

What it contains and why

Team capacity and calendar

The first page tells us who is available this sprint and gives us a rough shape of the team. Do we have an even balance between developers and content editors? Are we low on project management support this sprint? This is useful for planning.

The calendar keeps us focused on the key events throughout the sprint, as well as planned team absences.

Programme and projects

Next, we have a list of the current open projects in our portfolio. This gives us an at-a-glance summary of how much work we have on at the moment.

This includes key information about the projects, such as project manager, what stage in the project lifecycle it is, its size and complexity, and what the goals are for this sprint.

These goals are what I find most useful. They drive the team planning sessions, give us something to track at daily stand-up meetings, and during weekly strategy meetings, and they help keep me focused throughout the sprint.

Business as usual

The business as usual section tracks pretty much everything that cannot be regarded as project work, such as social media, consultancy, training, editorial calendar work, support and maintenance, and conferences. We make sure it’s clear who is responsible for each task.

We also have a ‘horizon gazing’ section that saves us from having to search through a shared Outlook calendar for upcoming events. This can include key University dates (start or end of semester, graduation, Raisin weekend, etc), conferences, team arrivals or departures, and our monthly digital advisory board.

This is also the section in which we keep track of our various subscriptions such as web hosting accounts, team chat, video and audio hosting, and content management system licenses. it’s just a way to keep these things visible and transparent, and to ensure that bought-in services won’t accidentally expire.

Professional development

A new addition to the document is a section that tracks when everyone has had their professional development review meetings. There is a transparency here that I like. It doesn’t list any personal details such as development goals, but it does help ensure that personal development is not forgotten and is regularly followed up.

Content management system

Another recent addition is a table that tracks how many content items are being published from our two primary content management systems, T4 version 7 and T4 version 8. This is for licensing and publishing purposes.

Retrospective objectives

Each fortnight we reflect on our processes and agree on actions to improve them. We create Trello cards to track their progress, but I also add the retrospective objectives to this document as a reminder.

Project burn down chart

A burn down chart shows a graphical representation of the total amount of work committed to, how much has been completed and therefore also how much is left to do.

The burn down chart for our last project

While we have a burn down chart on a whiteboard in the office, it’s really useful to also have a portable, paper copy for reference—particularly in meetings.

Programme summary

Another fairly recent addition is the external website programme summary. This is a big picture ‘map’ of the entire programme, broken down by project and phase. It’s colour-coded too, which helps. It allows us to see an at-a-glance status of the whole programme: what is complete, what is in progress, and estimated dates for the remaining phases.

About the sprint

And right at the end of the sprint planning document we have a short biography and photograph of the person after whom the sprint has been named.

Our current theme for sprint names is literary figures. Last sprint was Desdemona from Othello, this sprint is Elmo from Sesame Street. It’s usually educational and informative. Did you know, for instance, that Elmo was originally called “Baby Monster” and that his birthday is 3 February?

We usually mine Wikipedia for facts about the character, and choose a photo from Google Image Search, and credit the source for each.


Since its introduction, the sprint planning document has been a very useful tool, both to keep us focused and as an historical record to look back on what we have achieved. It’s like a cross between a paper-based dashboard that pulls together the key information and a map that enables us to navigate our way through each sprint.

Originally posted on the University of St Andrews web team blog.

Published by

Gareth Saunders

I’m Gareth J M Saunders, 52 years old, 6′ 4″, father of 3 boys (including twins). Enneagram type FOUR and introvert (INFP), I am a non-stipendiary priest in the Scottish Episcopal Church, I sing with the NYCGB alumni choir, play guitar, play mahjong, write, draw and laugh… Scrum master at Safeguard Global; latterly at Sky and Vision/Cegedim. Former web architect and agile project manager at the University of St Andrews and previously warden at Agnes Blackadder Hall.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.