Four ideas to help structure and organize the backlog

The backlog is a list of possible developments for improving a product (as you know, it is also the name of the best newsletter out there 😜). It is the place where future developments are prioritized and stored. Generally, it seems to be the case that we have too many ideas for improvements but not enough time to do them all right away. Therefore, backlogs tend to become large. In order to be able to handle this, it is so important to organize the backlog in a structured way.

Every team or Product Owner (PO) has different preferences on how to structure and organize the backlog. The structure will likely differ based on the lifecycle or maturity of the product. However, there are a few practices that I have found very helpful.

• Keep the backlog focused
• Have a system for discovery
• Plan future sprints
• Specific backlog sections

Let me explain how they can help. 

Email address:

Leave this field empty if you're human:

Keep a focused sprint backlog (and regularly purge it)

First, the thing that may be the most important and also the thing I struggle most with, keeping a focused backlog. It is very tempting to continuously add all kinds of ideas to the backlog as they come up. We tend to collect various stories and tasks and put them in the backlog because we will do them at some point. 

I have found that this then leads to an ever growing backlog with some items becoming older and older without being done. Thus, I recommend being very strict in what you add to the backlog. It’s best to only add stories that will actually be done within a reasonable amount of time (maximum a few months).

Related, I suggest purging the backlog on a regular basis. Trust me, if you haven’t yet implemented the story that you created two years ago, you likely won’t do it in the next two years either. You might as well delete it. 

Therefore, I recommend regularly going through all items in the backlog. For each and everyone ask yourself: Will we do this within the next sprints? If the (honest) answer is no, delete them. Resist the urge to keep them!

The topics the team or PO think should be implemented but for which the timing is unclear can and should be stored somewhere else. Similarly, to the individual, the development team needs some sort of system that ensures no ideas get lost and that they are added to the backlog when they need to be added. It makes sense to have a defined system for this product discovery.

Have a system for discovery

Product discovery – to me – is the process of identifying possible product improvements and bringing them to such a maturity level that they can be implemented. As such, it is a process from the abstract to the very concrete, it is what happens to ideas before they get added to the backlog. Every team should have a system or storage space for product discovery items.

There are plenty of ways to do this. Some popular methods are Opportunity Solution Tree, User Story Map, Technology Tree, creating a dedicated discovery backlog, or Impact Mapping. Roadmapping tools sometimes have places to store this (I have used Roadmunk and Productboard). Also, you can simply create an excel table where you store possible improvements. Whatever the method of choice, it’s important to be deliberate. 

Having a defined system for discovery is very helpful to create transparency for the mid to long term product developments. As such it is a great tool to use in stakeholder communication. Moreover, it helps avoid the backlog being filled with all kinds of items that may or may not be implemented at some point in the future.

Plan future sprints

I am a big proponent of creating and (roughly) planning the next handful of sprints. It doesn’t have to be very detailed planning – in fact, detailed planning is probably counter productive and wasted work. However, it does help to at least define sprint goals and understand the big ticket items that will be within the next sprints. 

My backlog usually includes sections for the next two to five sprints. Within those sections I often add the major stories that are to be included and formulate a sprint goal. This is of great help in communicating with stakeholders, particularly when creating the roadmap (and also checking whether the roadmap is still valid.) It also gives the team a sense of what is coming next.

Specific backlog sections 

Besides the upcoming sprints, it can be helpful to add even more sections within the backlog. They are not always needed and I am generally a fan of keeping it simple and not overcomplicating things. Thus, I encourage you to really evaluate whether you really need the following. Nevertheless, I think they are worth mentioning. 

In case you have things that need to be done regularly and are not (yet) automated, it can make sense to have a Recurring section in the backlog. This section includes the stories that can easily be copied and added to the sprint (and it also helps so that we don´t forget).

To be refined is a section where I add all stories that are not yet ready to be implemented but will be included in the next sprint. Usually, we add everything to this section a few days before the refinement. The team then already goes through them in the pre-refinement. Within our joint refinement session we discuss each item in this section in detail and afterwards they are all added to the next sprint.

In case you have a simple backlog structure without sections for the upcoming sprint, it probably makes sense to have a Ready for sprinting section. This is where all stories go that are fully refined and ready to be implemented. They should be ordered by priority. This is then where the stories for the next sprint come from. It is also the place where the team members go to pull additional work into the current sprint in case they are done early.

Be pragmatic

I am a pragmatic person and a big believer in adapting frameworks to the needs of the individual. I also don’t think there is necessarily a right or wrong way to keep the backlog. Therefore, I highly recommend trying different approaches and seeing what works for your team and product. 

You might use a sophisticated discovery backlog within some fancy tool where once a quarter you take the stories from and add them to the highly structured sprint backlog. You might just as well use a simple Excel list to store the ideas and have an unstructured sprint backlog where items are prioritized and then added to the sprint. Or you might use something in between. The important thing is to consider different approaches and figure out what works best.

Coverphoto by Jeff Frenette on Unsplash