This article aims to provide you with a possible example of a backlog to construct: the backlog example. Building a backlog, especially for the first time, can be challenging. Therefore, I will offer you some tips to help you get started.
You can watch the Agile Minute video on backlogs here:
An Example of a Backlog
Starting with Backlog Definition
Here is the definition of a backlog (also known as a product backlog) that I provided on this blog:
The backlog of a product is the collection of needs gathered to create the desired product. This may involve user stories as well as technical items, spikes, or even bugs.
Since we are working with agile methods, it’s important to understand that the backlog’s scope is flexible; elements can appear and disappear as the product is developed.
You can also watch the “La Minute Agile” video on the topic of the product backlog here:
Creating Your First Backlog
For initiating your product backlog, the story mapping exercise is highly effective. It allows you to establish an initial vision of the backlog without diving into the details.
You can read our comprehensive article on how to conduct a story mapping workshop here: Story mapping
And if reading isn’t your preference, you can also watch our detailed video that explains the process of story mapping here:
For experienced individuals: Agile Framing (100% agile framing for your project) offers a logical sequence in the “vision” phase. Feel free to explore its approach: the vision of the product (French blog).
Here is the outcome of a story mapping session focused on a classic e-commerce site:
story mapping – backlog example
Constant Evolution is Key for Backlogs
A backlog is a collection of dynamic elements:
- Items will be removed
- Items will evolve
- New items will be added
In contrast to traditional specifications, backlog elements are constantly evolving. It’s not necessary to document everything in advance; instead, allow room for real-time evolution as needed.
In essence, can we say that a backlog is never truly finished?
Just-in-Time Specification Writing
Each item will be associated with a specific requirement that needs to be fulfilled. For instance, using our previous example: “rate the product.”
The product owner will focus on creating the necessary specifications for fulfilling this requirement just before development begins. This approach has several benefits:
- Up-to-date specifications that reflect any discoveries made during the product’s development
- Avoidance of obsolete elements in the specifications (particularly those written months in advance)
- Avoidance of unnecessary work in case certain items are eventually not developed
While it may be a bit challenging initially, this practice optimizes product development.
A product owner who is new to the role can use structured user story formats like the A4 story.
Story A4: a highly effective user story format
Thus, only the items planned for the next sprint will have fully detailed specifications, while others remain at the title stage.
However, if a roadmap (agile, of course) is needed, it’s still possible to estimate user stories collectively:
Estimate using Extreme Quotation
Conclusion: Backlog Example
I hope this article helps you in creating your product backlog. It’s not always easy to know where to start, especially when you’re new to the role of a product owner.
Be the first to comment