Questions to ask about your Sprint Backlog

Chances are that if you or your teams have given this Scrum thing a try, you may have seen something similar to this image below:

Yep, that's what many teams would call their Sprint Backlog. As a quick refresher, this particular artifact is the output of the Sprint Planning ceremony for those teams leveraging Scrum. Digging a bit deeper into where this came from, and what happens to it after the ceremony, is very telling.

After a conversation I had recently, it's apparent that many teams have forgotten the intent of what this particular artifact represents. This is the short ranged, sufficiently detailed plan that the Team (not the ScrumMaster, not the Product Owner) has come up with for the upcoming segment of work aka the Sprint.

I offer up the following questions that can start off some real, honest discussion with respect to a Team's Sprint Backlog:


1. Who created the plan?

More times than you'd think I come across Teams where they tell me they are "handed" their sprint backlog. Who actually created the plan is a very telling sign.

2. Is the plan visible?

There's very little value in a plan that doesn't exist. If a plan is in "someone's head" it's not really visible, is it? If the Sprint Backlog is visible in some form, Team members can have a visual representation of the plan.

3. Is it clear what Product Backlog Items (PBIs) were selected for the next Sprint?

To create the Sprint Backlog the Team selects a number of PBIs from the top of the Product Backlog. When looking at the Sprint Backlog, it should be clear what PBIs were selected prior to creating the plan.

4. Do those PBIs have enough information for the Team to break down?

A really neat concept called "Definition of Ready" has been getting some great traction, and who's concepts should be considered when teams select the items to create their Sprint Backlog.

5. Does the plan have enough detail where it's clear to them when the ball is moving forward?

A plan that simply states "do some things" is one thing, but Teams should strive to have enough detail to have a conversation with one another about how things are going. There should be sufficient detail in the plan about how the team makes their daily commitment.

6. Does the Team interact with the plan?

This plan that the Team creates is something that they converse about and update on a regular basis. Think about the types of conversations and interactions the Team has with the plan, which can be very telling about the quality of the plan and your implementation of Scrum overall.


Have some honest discussions about the quality of your Sprint Backlog. Asking a few simple questions like the ones above can shed some light on how things are going, and may reveal some opportunities for improvement.

Remember, at the end of the day the Sprint Backlog is a plan that the Team comes up with, and provides the snapshot of the work that they plan to knock out in the upcoming Sprint. They own it, nobody else!

Featured Posts
Recent Posts