Backlog example

This article aims to show you a possible example of backlog to build: backlog example. It is not always easy to build a backlog especially the first time. So I will give you some tips to get you started.

You can watch the agile minute video on the backlog:

Backlog example

Let’s start with the backlog definition

Here is the the backlog definition (also called product backlog) that I had given on this blog:

The backlog of a product is the set of needs collected to create the desired product. If we thinks of user-stories right away, it can also concern technical items, spikes or even bugs.

As we are in agile methods, we must understand that the scope of the backlog is variable; we can see elements appear and others disappear throughout the product development.

 

Backlog definition

You can watch the video of “La Minute Agile” on the subject of the product backlog:

How to create your first backlog?

To start your product backlog, the story-mapping exercise is really excellent. It makes it possible to constitute a first vision of a backlog without the details.

You can check out our full article on how to do the story mapping workshop: Story mapping

And if you don’t like reading, you can also check out our full video that explains how to do this story mapping:

For the experts: agile framing (framing 100% agile for your project) also offers a logical sequence in the “vision” phase. Don’t hesitate to consult its progress: the vision of the product (french blog).

So here is the result of a story mapping done about a classic e-commerce site:

The key to a backlog is its constant evolution

A backlog is a set of living elements:

• items will disappear
• items will evolve
• and some items will be created

Contrary to specifications, the elements of the backlog are constantly evolving. You should not write everything in advance but allow yourself a real ability to see it evolve in real time (as needed).

So to put it simply, a backlog never ends?

Just-in-time specification writing

Each item will be linked to a small need to be fulfilled which will need to be specified. Example from our previous image: “rate the product”.

The product owner will work to have the specifications that complete this need written just before to development. And there are several reasons for this:

• writing of up-to-date specifications in relation to the discoveries that the advancement of the product can bring
• avoid the discoveries of obsolescence elements in the specification (especially when it is written 6 months before)
• avoid unnecessary work: if some items will finally never develop.

It’s gymnastics that is not obvious at the beginning but that optimizes the product development.

A product owner who discovers the job will be able to use simple but structured formats of user-stories such as the A4 story.

Story A4: very effective user-story format

Thus only the items for the next sprint will be fully specified and the others will remain at the stage of a single title.

However, if it is necessary to have a roadmap (obviously agile), it is always possible to make a mass estimate of user-stories:

Let’s estimate with Extreme Quotation

Conclusion backlog example

I hope this article will help you to build your product backlog. It is not always easy to know where to start, especially when you are discovering the job of product owner.