Make your Product Backlog Speak the Whole Story

The Conventional Product Backlog

contains an ordered list of requirements often written in a User Story form. These fragmented “stories” do not give us a clear picture of what the Product is, or what values they bring as a whole.
The Product Owner, the Development Team and stakeholders all depend on this backlog to fill their roles in Scrum yet this very backbone which they rely on does not present a mental image of the product that’s needed for the team to bring out the product’s value or advantage.

Imagine you’re a stakeholder of our latest task management software — Quire

and you’ll have access to a Product Backlog
that, by convention, looks something like the list below:

Each of these user stories is self sufficient in portraying a requirement; however, by sorting them with respect to their Return On Investment, we've taken each item out of their context—the core value that they contribute to the product.

Instead, let’s try a different approach in creating a Product Backlog for Quire, with Quire

We first put down the core values that drive the development of our product:

!Product backlog](https://thepracticaldev.s3.amazonaws.com/i/aq2i8n55ggh4sosmy9e7.png)

Although these “epics” are too large to be estimated with any reliable accuracy, they do paint a better picture of what values this product would bring.

We then expand on each epic, specifying more stories, or even more epics, that would build on top of these foundations toward our product:

Notice this tree-like structure fits naturally with how we had developed our ideas.
If we make the analogy that the product is a tree, then the the epics would be the main branches of the tree. With the conventional Product Backlog, we are picking up a leaf here and there at the ends, stacking them up without seeing what the whole tree looks like.

With Quire’s tree structure, we can nest stories within other stories(or epics) so we’re always made aware of their context and not lose focus on what value we wish to bring forth in the product.

But we are supposed to prioritize the Product Backlog Items?

The convention dictates that we put the Product Backlog Item with highest priority on the top of the list; but there are other alternatives to highlight our immediate concerns than a sorted list.

We can define priority level tags such as PL1, PL2, and so on; upon the Product Owner gets all the necessary information to prioritize the tasks, he or she can assign these tags to tasks that are in considerations for the upcoming Sprints:

Although it’s best to estimate efforts on tasks as a group in a meeting room, with team members often reside on different continents, Quire’s live chat feature is a good alternative

During the Spring Planning Meeting, when it comes to picking the items to commit to the next Sprint, team can then use Quire’s filter function to display only the items that are of immediate concern:

A Product Backlog should not only contain fragmented user stories

rather, it should speak the whole vision your team has for the product. Coarse requirements better portray value and as we develop them into finer items, they branch into items that are more tangible so we can assess their cost more accurately.

A tree structure naturally capture this branching and retains information encoded in both, and as a whole.

We've only tapped into how Quire can help us to reinvent the Product Backlog. We’ll explore how Quire can be used to deal with other aspects of Scrum in subsequent articles.