Skip to content

Sprint Backlog – How to Organize For Top Value

Sprint Backlog - How to Organize for Value
Sprint Backlog – How to Organize for Value. Flexibility in your Agile software development sprint backlog is needed. A way to help gain this is by not overloading sprints with work and that work all need to be completed.

First of all, what is the sprint backlog? In Scrum, the sprint backlog is the organization of the work to be completed. The accumulated repository of work that is being worked and the work that could be done in the future. According to some definitions, the sprint backlog also contains other meanings. For our purposes here, I want to focus on it as a tool to organize the work to be done by a team or teams.

Let’s dive into how it is organized, shall we!

Table of Contents

Organize the sprint backlog into 3 categories of work

It is very helpful to the team to organize the sprint backlog in such a way that the work priority is well understood. A favorite method of mine is to organize the larger backlog into priority order. Must have work items at the top. Next are the items that should be done. Lastly are the items that could be done. These explanations are pretty self-explanatory, so I will skip over that.

In addition to having the larger backlog organized in such a way, each upcoming sprint of work should follow this prioritization order. The reason for this is that you will build flexibility into your sprint backlog. Which enables the success of the team. Or in other words, if you fill a sprint full of items that are must-haves, there will undoubtedly be some items that aren’t completed.

Without getting into all of the details there it is because work happens. Things change and need to change. So by building flexibility into the sprint backlog, you are really building success into your sprint backlog.


product roadmaps relaunched

Check out Product Roadmaps Relaunched

To help with Agile estimation and the planning of future work, better ways to create roadmaps are needed. Roadmaps that account for and embrace the uncertainty of changing backlogs and planned work. Product Roadmaps Relaunched helps understand how to plan in an Agile way.


Place “must haves” at the top of the sprint backlog

The must-have items are the items you have to complete. These should be the first items in the sprint. Exact numbers of how many must-have items can vary, and they should, to remain flexible. The main point here is that you can’t have too many must-have items. As they will not all be able to be completed.

Next are the “should have” items

After the must-have items are the should haves. These of course are the items that you really should get to. However, there is some flexibility in if they get done in that sprint or some upcoming sprint.

Keep some “could have” items in the sprint

Lastly are the could have items. These are the complete wish-type items. They do not have to be done. A lot of them would not have to be done ever. Though if they do not have to be done ever, I would question why they are even in the backlog. I would argue most teams have other work, that would gain greater value, that work that doesn’t have to be done ever.

Tips to help organize in the sprint backlog

If using Jira, you can flag these items using priority. That can help to understand what is must, vs should, vs could have items. Another way is to use labels. Jira tickets can have the labels for these priority levels. Or, lastly, you can use generic stories in the backlog view. Where the title is a placeholder to indicate must have, should have, could have. Then everything above the given story falls into that category, everything below it falls into the next.

All of these are helpful means to organize the Jira stories. There are others too and use whatever works best for you. The important thing is to remember to use this type of status or priority level on the stories, to help enable work by the team.

Just like your entire sprint backlog is, or at least mostly is, in priority order. Where top priority items are towards the top and lower-priority are towards the bottom. Each individual sprint backlog should reflect this general prioritization. Having top priority items, middle priority, and lower priority. The exact ratios of each are flexible.

But if the sprint is full of top priority items, then it is your sprint and your planned work that is not flexible. As work will inevitably change along the way. Or something will go wrong. And you will have to adjust the course. But a sprint that is completely full of must-do work leaves no room for any adjustments.

Additional content and books that help build your sprint backlog



Another great read that helps to understand the sprint backlog and how to organize the work can be found here.