The Scrum Guide™ states that the outcome of a sprint planning event should be a list of Product Backlog Items (PBIs) and a plan on how to deliver them. Similar to other things in the Scrum framework, a concrete definition of what the plan should look like is not provided. Authors of the Scrum framework give you the freedom to choose what works best for you.

So, I’ll show you a simple technique that we use at Setapp for this purpose. We call it the sprint timeline.

How does the timeline work?

The timeline is a physical artifact that should be located in a place where all team members can interact with it. Below you can see an example of a sprint timeline for an imaginary mobile application with a web back-end:

The rows denote the members of the development team and the columns denote the days of the sprint. The cards are development tasks. The red “X” cards are the days where team members are not available for development work.

First, you place the task card on the day that you plan the task to be done (as in Definition of Done). When the task is not finished on the planned day, then you need to move the card to the right and place a red exclamation mark on it. This shows that the task is problematic and should be investigated. You can see that ‘offer list view’ is causing problems and Ben probably needs some help with it. For tasks that are finished, place a green checkmark on respective cards.

Below you can see how a sprint timeline looks in one of the projects at Setapp:

This timeline tracks the work of a six-person development team and four people that are not in the development team but whose work has to be coordinated with the team. Instead of team member names, we use funny images that relate to people’s nicknames.

A timeline is an excellent Information Radiator that gives anyone that passes it an opportunity to get valuable insight into the sprint progress.

Btw, we are looking for a Scrum Master. If you are up for the challenge then send your application now!

Augment the vicinity of the timeline

You can also augment the vicinity of the timeline with additional information like:

• A printed sprint goal to help team members stay focused
• A list of actions from the previous sprint retrospective to remind team members 
• Topics for next the sprint retrospective to make sure that they are not forgotten
• Funny images and team memes to keep the spirits high

Planning the sprint

A timeline is an invaluable tool for sprint planning. We start sprint planning with a potential list of stories to be done in the next sprint that are valuable to the Product Owner (PO) and then form some coherent goal. The stories are usually estimated beforehand (most likely with planning poker) so that the PO can start with a rough list that should be doable in the next sprint taking the current velocity of the development team into account. Planning then goes as follows:

1. Developers update the sprint timeline with their planned holidays. This ensures that the capacity during the next sprint is known. They do this by placing cards with a red “X” marks the days they will be off.
2. PBIs are split into technical sub-tasks. In this step, there’s usually a lot of discussion about technical details of possible solutions. Some PBIs are re-estimated because team members have discovered some previously unknown details.
3. Technical sub-tasks are printed and placed on the timeline on days that team members plan to have them done. In this stage team members may discover, that there’s too much work and some PBIs won’t fit in the sprint

The final list of PBIs and the timeline filled with sub-tasks constitute the sprint plan. Off to work now.

Monitoring the sprint

Every day, during the daily Scrum meeting developers, gather near the timeline and update it if necessary. Developers may have discovered additional work to be done that needs to be added to the plan or some work may have turned out to be unnecessary.

When a task wasn’t finished as planned it is an early warning sign that the forecasted list of PBIs may not be done in this sprint. At this point, the development team should probably talk to the PO and maybe change the planned work in a way that will fit into the sprint without compromising the sprint goal. Some stories may also require reestimation.

Things to watch out for when using a sprint timeline

A timeline is a great tool. However, we have seen some negative patterns when using it in our projects which adversely affect our work. I’ve listed them below with the possible solutions:

1. 1. The timeline is not updated when the plan changes
      Sometimes team members forget to make necessary changes to the plan when new information is discovered. This is very dangerous because the timeline starts to be based on falsehoods and stops showing real progress. The Scrum Master should intervene and remind people that an up-to-date sprint plan is essential for effective development. 
   2. No proper discussion when the plan falls apart
      When a task is moved to the right some developers fail to have a proper conversation about it and just brush it off. Every time this happens there should be a thorough discussion on what should be done to get the sprint back on track.
   3. Ownership of work on a person and not on the team
      The fact that tasks on the timeline are visually assigned to people can sometimes weaken the mindset of shared team ownership of the work in a sprint. The Scrum Master should be on the lookout for symptoms of such behavior. The presence at daily Scrum as a passive member can help.
   4. The work status is not updated in the issue tracking system
      When a timeline is fully implemented, developers sometimes get so used to it that they may forget to properly update the status of tasks in the tracking tool. This may be especially problematic when the PO is not co-located with the team and doesn’t have access to the timeline. Without updates in the tracking tool, the PO may be deprived of necessary information. The Scrum Master should monitor the situation and teach the development team to keep the issue tracker up to date.

Conclusion

A sprint timeline is a useful tool for planning and monitoring your sprint. We use it here at Setapp with great success. What technique do you use for your Sprint Planning? Let me know in the comments below and if you have more questions about the Sprint Timeline technique email me at milosz.kosobucki@setapp.pl