{"id":60,"date":"2024-02-02T18:00:00","date_gmt":"2024-02-02T18:00:00","guid":{"rendered":"https:\/\/permutationcity.co.uk\/bp\/?p=60"},"modified":"2024-04-28T09:11:52","modified_gmt":"2024-04-28T09:11:52","slug":"how-to-manage-a-backlog","status":"publish","type":"post","link":"https:\/\/permutationcity.co.uk\/bp\/2024\/02\/02\/how-to-manage-a-backlog\/","title":{"rendered":"How to manage a backlog?"},"content":{"rendered":"\n

One of my friends had an issue with assumption that tasks rise towards the top of the backlog in\na previous post<\/a>. That is<\/strong> an\nassumption from working on Jira with a particular team and isn’t how backlog or tasks lists always work.<\/p>\n\n\n\n

Working with a prioritised backlog<\/h2>\n\n\n\n

It’s very frustrating when you ask which task is most important, so you can allocate your time effectively,\nonly to be told that all your tasks are high priority. Surely if everything is high priority then nothing is?\nHaving a single backlog in priority order makes the situation so much clearer.\nThe task on top has the highest priority. The next task might be important but it is less important.<\/p>\n\n\n\n

You could use this as the single mechanism to decide what gets done next. In some teams everyone might be able\nto do everything. However for most teams I think it makes sense to look at who is available to do the work.\nIn games development you might well have artists and coders working on the same team and their skills are not\ninterchangeable. It’s very helpful, in general, for letting someone pick up an important task quickly.<\/p>\n\n\n\n

Unfortunately the backlog doesn’t order itself, wouldn’t that be useful. Instead it has to be regularly\ngroomed and updated to reflect the projects current priorities. It’s also a chance to expand on the details\nin each tasks, break apart tasks into sub-tasks, or remove tasks that are no longer needed. As the backlog\ngrows grooming it becomes more substantial task. (Or, as my friend found, just doesn’t get done.)<\/p>\n\n\n\n

The funnel<\/h2>\n\n\n\n

I found that as the backlog became very long, over 100 tasks, it became unwieldy. This might be a situation\nwhere seeing the whole list in one glance<\/a> is\nbeneficial. I can re-order a single screen of tasks fairly quickly but more than that becomes significantly\nharder. You could move some of the tasks to an archive but does that mean they would just be forgotten?<\/p>\n\n\n\n

I came up with a variation of the backlog, the pyramid<\/strong> or funnel<\/strong>.\nIf a normal backlog is a pipe with a constant diameter then the funnel starts wide and narrows towards the tip.\nThe highest priority task is at the tip, next that are two high priority tasks, then three medium\npriority tasks. The idea is to give a good sense of priority but reduce how long the grooming takes.\nHigher up the priority scale you can think harder about what’s more or less important. Lower down the\npriority scale you can waste less time. A fixed size to each level means that everything can’t have the\nsame importance. As high priority tasks are finished lower priority tasks can be moved up. I think grooming\nthis would be easier as well because you don’t need to find the exact position from something just a general\nlevel.<\/p>\n\n\n\n

Outer and inner backlog<\/h2>\n\n\n\n

Priority isn’t everything. It can be frustrating when useful but lower priority tasks never rise up to the\ntop of the backlog. This can easily happen if there’s always a stream of new tasks whether that’s\nbug fixes or new features that created at the top of the backlog. Unfortunately I think this can happen in\nScrum when the product owner has insufficient understanding of the internal workings of the product.<\/p>\n\n\n\n

I wonder if keeping a separate backlog for product deliverables, managed by the owner, and product internals,\nmanaged by the team, would be better. An external backlog would be easy to update\nwhen thinking about the next release. The internal backlog could be easily adjusted to reflect the priorities\nof the external one. It could also pay more attention to tasks that improve the teams ability to deliver\nin the future. I think the product owner should concentrate on what to deliver and the team should\nconcentrate on how to deliver it.<\/p>\n\n\n\n

There is going to be some overhead involved having two backlogs. Each task in the external backlog needs\nto be have a related task in the internal backlog. It’s not necessarily a one to one relationship. One\nexternal task could have three internal tasks. Three external tasks could all be solved by one internal tasks.\nRe-ordering the external backlog would need to be reflected in the internal backlog. Again, that’s not one to\none.<\/p>\n\n\n\n

Automating priority<\/h2>\n\n\n\n

I joked about the backlog not ordering itself earlier on but is that possible? When I groom a backlog\nI’m looking at how important a task is to the current delivery, how long it’s estimated to take,\nthe availability of resources, which other tasks are related. If that information is available to me\nthen it could also be processed automatically. An external backlog would be useful to give an overall\nimportance and all the related tasks would have to be explicitly linked together but it sounds possible.<\/p>\n\n\n\n

Presenting this as the primary backlog might be too much. I think it could get confusing if the tasks\nwere constantly re-ordering themselves. It could be presented as additional information alongside the\nexisting backlog. Perhaps colouring the task to show how far it was from it’s “ideal” position.<\/p>\n\n\n\n

On balance<\/h2>\n\n\n\n

While I have worked with a prioritised backlog everything else are just ideas. They would be interesting to\ntry but no guarantees. They could be built with custom pages but it might be possible to use Jira or similar\nto try some of these.<\/p>\n","protected":false},"excerpt":{"rendered":"

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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_import_markdown_pro_load_document_selector":0,"_import_markdown_pro_submit_text_textarea":"","footnotes":""},"categories":[1],"tags":[11],"class_list":["post-60","post","type-post","status-publish","format-standard","hentry","category-general","tag-planning"],"_links":{"self":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts\/60","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/comments?post=60"}],"version-history":[{"count":2,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts\/60\/revisions"}],"predecessor-version":[{"id":200,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts\/60\/revisions\/200"}],"wp:attachment":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/media?parent=60"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/categories?post=60"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/tags?post=60"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}