nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Who do you assign distant backlog tickets to?

Kat Warner

Issues often fit into time categories of:

to do in the next 1-2 sprints
to do soon, sitting at the top of someone's backlog
to do some time, maybe, eventually

The last category where I work are a mix of project tasks that have been scoped but not scheduled; miscellaneous tasks we will get to "when we have time"; and various tickets created which have yet to be reviewed by the product owner and scrum master.

Where does your organisation store these tickets?

Do you have tickets that exist long before they get assigned t someone who will actually work on them?

Comments

Jimmy Seddon

Hey @Kat Warner,

This is a great question!

For us, a number of these items sit unassigned. What we have been trying to get better at is removing that third category all together. By that I mean if there are no plans to address the item within the next 6-12 months it gets closed with a resolution to the effect that there are no plans to complete that work.

That way we are being more transparent internally around what the priority items are and discussions can happen at the director level to shift priorities if needed. We found if we left things open those conversations wouldn't happen, so this forces the communication which keeps everyone on the same page.

-Jimmy

Kat Warner

I completely forgot that unassigned was an option!

Scott Theus

I love the question! I'm helping to lead an agile transformation at my company, and I get this one quite a bit.

Just like @Jimmy Seddon , I recommend that our project leads leave the backlog items unassigned. Most of the teams here that are new to Agile, so they start with a basic workflow on a Kanban board, with a Backlog a To Do column. Once a backlogged item is assigned it moves into To Do.

-Scott

Tim Keyes

I agree leaving items unassigned in the backlog seems like a great option. Consistent grooming of the backlog can help prioritize the next user stories/ tasks to be assigned to a develop team or a specific developer depending on the size of your organization. This also leads into have a separate team and program backlog as desired/ necessary.

Mark D. Stock

Hi Kat

I am slightly confused by your question. You mention Sprints, so can I assume you are using Scrum? I've never seen Product Backlog Items assigned to individuals. To me, Backlog Items are refined, and then added to a Sprint. Once the Sprint starts then Sprint Items are assigned to individuals. If anyone needs to work on a PBI then they can raise a Spike or Task and take that into the next Sprint, but the original PBI remains on the Backlog unassigned.

Previously I spent many years working on e-commerce products - one product, one Product Backlog. But where I am now we have set up Feature Teams. Here, multiple teams share a single Backlog, and each has a different view based on a filter on the assigned team. The assigned team is a different field to the assigned individual, so the same rules apply to assigning Items to individuals once the Sprint starts.

In terms of your time categories, the Product Backlog should be ordered by priority, with the highest priority items (need doing next in your case) at the top. The team then selects items from the top for each Sprint. So all Items are stored on the Backlog, and during refinement you can ignore the lower part of the Backlog based on time available. So yes, we do have Items that exist long before they get assigned to someone who will actually work on them. These items are only refined further as they rise to the top of the Backlog.

It may be worth reviewing your Backlog periodically and chopping off items at the bottom that will never get done.

2p please.

Mark

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

agile