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:

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: