One of my friends had an issue with assumption that tasks rise towards the top of the backlog in a previous post. That is an assumption from working on Jira with a particular team and isn’t how backlog or tasks lists always work.
Working with a prioritised backlog
It’s very frustrating when you ask which task is most important, so you can allocate your time effectively, only to be told that all your tasks are high priority. Surely if everything is high priority then nothing is? Having a single backlog in priority order makes the situation so much clearer. The task on top has the highest priority. The next task might be important but it is less important.
You could use this as the single mechanism to decide what gets done next. In some teams everyone might be able to do everything. However for most teams I think it makes sense to look at who is available to do the work. In games development you might well have artists and coders working on the same team and their skills are not interchangeable. It’s very helpful, in general, for letting someone pick up an important task quickly.
Unfortunately the backlog doesn’t order itself, wouldn’t that be useful. Instead it has to be regularly groomed and updated to reflect the projects current priorities. It’s also a chance to expand on the details in each tasks, break apart tasks into sub-tasks, or remove tasks that are no longer needed. As the backlog grows grooming it becomes more substantial task. (Or, as my friend found, just doesn’t get done.)
The funnel
I found that as the backlog became very long, over 100 tasks, it became unwieldy. This might be a situation where seeing the whole list in one glance is beneficial. I can re-order a single screen of tasks fairly quickly but more than that becomes significantly harder. You could move some of the tasks to an archive but does that mean they would just be forgotten?
I came up with a variation of the backlog, the pyramid or funnel. If a normal backlog is a pipe with a constant diameter then the funnel starts wide and narrows towards the tip. The highest priority task is at the tip, next that are two high priority tasks, then three medium priority tasks. The idea is to give a good sense of priority but reduce how long the grooming takes. Higher up the priority scale you can think harder about what’s more or less important. Lower down the priority scale you can waste less time. A fixed size to each level means that everything can’t have the same importance. As high priority tasks are finished lower priority tasks can be moved up. I think grooming this would be easier as well because you don’t need to find the exact position from something just a general level.
Outer and inner backlog
Priority isn’t everything. It can be frustrating when useful but lower priority tasks never rise up to the top of the backlog. This can easily happen if there’s always a stream of new tasks whether that’s bug fixes or new features that created at the top of the backlog. Unfortunately I think this can happen in Scrum when the product owner has insufficient understanding of the internal workings of the product.
I wonder if keeping a separate backlog for product deliverables, managed by the owner, and product internals, managed by the team, would be better. An external backlog would be easy to update when thinking about the next release. The internal backlog could be easily adjusted to reflect the priorities of the external one. It could also pay more attention to tasks that improve the teams ability to deliver in the future. I think the product owner should concentrate on what to deliver and the team should concentrate on how to deliver it.
There is going to be some overhead involved having two backlogs. Each task in the external backlog needs to be have a related task in the internal backlog. It’s not necessarily a one to one relationship. One external task could have three internal tasks. Three external tasks could all be solved by one internal tasks. Re-ordering the external backlog would need to be reflected in the internal backlog. Again, that’s not one to one.
Automating priority
I joked about the backlog not ordering itself earlier on but is that possible? When I groom a backlog I’m looking at how important a task is to the current delivery, how long it’s estimated to take, the availability of resources, which other tasks are related. If that information is available to me then it could also be processed automatically. An external backlog would be useful to give an overall importance and all the related tasks would have to be explicitly linked together but it sounds possible.
Presenting this as the primary backlog might be too much. I think it could get confusing if the tasks were constantly re-ordering themselves. It could be presented as additional information alongside the existing backlog. Perhaps colouring the task to show how far it was from it’s “ideal” position.
On balance
While I have worked with a prioritised backlog everything else are just ideas. They would be interesting to try but no guarantees. They could be built with custom pages but it might be possible to use Jira or similar to try some of these.
Leave a Reply