A product backlog, roadmap, and priority model
I’ve always struggled with Jira. And I don’t think I’m alone. It’s the one tool we seem to be helpless without, but also the one tool no one seems to have nice things to say about. Too much configurability, perhaps?
I’ve worked in teams that use Jira relatively well, teams that use it relatively poorly, and teams that tried to use it but gave up either because no one could see the value, or because it put too many obstacles in the way of getting to a place of value.
So on occasion, my mind turns to how I might design a product backlog model. If I had unlimited time and goodwill from those who would have to suffer through the various iterations, of course.
It always struck me that dependencies were the thing that made planning out work somewhat difficult. Epics are blocked by stories, stories by tasks, and tasks by subtasks. But then some tasks are also blocked by stories, or even epics. Not to mention multiple other tasks. It gets messy quickly. Most task management tooling provides ways to link tasks together to note these blocking relationships, but it is left up to us to figure out what that really means for our immediate priorities.
Could there be a way to just see the next steps and nothing else? A way to chip away at a problem, one task at a time, in the right order, until it was eventually solved?
Maybe just focus on what’s blocking what?
I envision a system where work is described by tasks. They can have titles, descriptions, estimates, assignees… all the regular meta data. But they do not have a type. They are not epics, stories or subtasks. They are just tasks.
And they can block each other.
Each task could be linked to every other task that cannot be completed until it is completed. These relationships may form naturally, as high-level requirements become more and more technical. And they may also form during development, as new data and challenges emerge.
By using this information, only those tasks that are not blocked—so-called edge tasks—are made visible on the task board. The task board itself being some form of simple To Do, Doing, Done board, like we might set up on Trello. Whenever a task becomes unblocked, it appears on the board, ready to be worked on.
Project owners could limit what section of the backlog is worked on by allowing only certain tasks (and, by extension, their related blocking tasks) to be shown. This would also surface seemingly unrelated tasks that are blockers, maybe even several times removed. If estimates have been used, a quantifiable number for the expected and unexpected work could be tallied for the project owner.
If a task is not actionable in and of itself—that is, it is completed when the tasks that block it are completed—it could be marked as such, and its completion automated based on the tasks that block it.
A practical example
To visualise how the model might work, consider the example illustrated below. The top-level task is to incorporate a simple voucher code option into an e-commerce checkout flow. To achieve this, all of the various tasks and their blocking tasks have been plotted in accordance with the model.
Of these tasks, the following are not directly actionable, and are deemed to be completed when all of their dependent tasks have been completed:
- Voucher Creation
- Voucher Deletion
- Voucher Administration
- Add Voucher Field To Checkout
- Accept Vouchers During Checkout
- Offer Discounts To Customers
We might think of these as epics or high-level stories.
As work progresses, we can see that only certain tasks (shown in green) are surfaced for people to work on. We can also see how, as tasks are completed, other tasks that have become unblocked become visible and ready to be worked on:
When the tasks that are not directly actionable become unblocked, they are automatically marked as completed and unblock other tasks in turn.
This is a simplified view, of course. In reality, any task of any type could be set as a blocker for any other task of any type. The dependency graph on a real project would be incredibly complex, but to the user all of that complexity would be hidden—each task need only to be linked to the ones it blocks.
To users of the system, the above flow would look like this on a task board:
By mapping which tasks block which other tasks, and focusing on that relationship as the primary aspect of the system, we could very quickly establish a backload, roadmap, and priority model where single units of value-add work are exposed in the right order, and the wider application can be built in a sensible (hopefully backwards-compatible) way.