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; } } }

How do you plan and prioritise your backlog in Jira?

Dave

I've been working on a Forge application to assist teams using scrum (it's already available for free on the Atlassian Marketplace). This app uses individual capacity to guide you on how many work items you should include in upcoming sprints. This analyses both work item count and story point velocity.

I'm iterating on an automatic sprint scheduling algorithm and I'm interested to understand how other Jira teams manage their backlog.

When it comes to planning future sprints I'm interested in how many sprints you plan in advance, how far down your backlog you estimate work items (if at all!) and what measures you take to ensure that work items are done in a sensible order.

Do you rely solely on the work item rank? Do you lean on priority assigned to work items? Do you use flags?

How do you manage dependencies? For example do you check to see if a sprint contains work items that depend on each other or do you try to ensure that dependent work items are scheduled synchronously?

Are you guided by thematic objectives? (e.g. do you try and work on a fixed distribution of bugs, engineering health and feature work?)

Do you plan for 100% capacity or do you only partially fill a sprint in the knowledge that some unplanned work always finds its way in (despite your best efforts!)

If this sounds a little bit like the "Calculate" from Portfolio (now "Auto Schedule" in Jira Plans) then this isn't a co-incidence as I used to work on that product a long time ago at Atlassian but this is very much just a side project on a topic that greatly interests me (the difference being that this is constrained to a single board).

At the moment I'm just relying purely on rank, but I'm wondering what other aspects of work items I should look at.

If anyone is willing to share any insights on any of the above then I'd be very grateful.

Also, if you'd like to give my app a try and let me know what you think I'd be keen to hear your feedback.

Thanks!

Comments

Walter Buggenhout

I am quite intrigued by the use case, @Dave - more specifically to what extent sprint planning can be really 'automated'.

I have always considered sprint planning and associated backlog grooming as a very important and central aspect of the decision making and communication processes for agile teams. Considering that work is defined and refined on an ongoing basis, sitting together and having discussions about what goes into a sprint, if it meets the minimum requirements to be picked up by the delivery team etc has always been of utmost importance to me to create shared understanding among the team.

So I am quite curious how this is not overthrown by automating sprint planning and would still get the attention it needs within the team.

Also curious how other group members think about this ...

Walter Buggenhout

To this question:

When it comes to planning future sprints I'm interested in how many sprints you plan in advance, how far down your backlog you estimate work items (if at all!) and what measures you take to ensure that work items are done in a sensible order.

I used to work in a scrum team delivering on a bi-weekly basis and building custom built software for external customers. We did not plan for more than 2 sprints ahead, as we were writing stories while the developers were building and had a good cadence delivering continuously that way.

The order of things was very much determined by a story mapping exercise we did early on to define (at a high level) everything that would be required to build a working product. We tried to create modular software, that could be built independently as much as possible. Part of the story mapping exercise was to identify the core components we would need first to create coherent features afterwards. Work was organised within epics that could then be built as consistent pieces of working software.

For planning, we would write and deliver stories to the team in line with those priorities, so they would appear in the backlog in a logical order. Linked to the epics we could then use to communicate on progress with the customer as well.

Sensible order can also be driven by dependencies. We would use Jira links between work items for that, but we would only define them if they were really blocking.

Dave

Thanks @Walter Buggenhout ... I've probably used the wrong verb with "automated"... not sure what the right one is, so it's not that sprints would continuously be automatically updated, but rather planned when you tell them to using available data (historical velocity combined with future availability) being the main ones.

What I'm hoping to achieve is to take some of the heavy lifting out of the process so that the app does what you would have done anyway.

Assuming all work items are already ranked then "chunking" them into sprints based on velocity isn't really too tricky.

But there are obviously nuances, the obvious one being whether or not your backlog is even ranked in the first place.

My goal is to help teams achieve predictable delivery, my limited observations are that teams have a tendency to overbook sprints, and this prevents longer term planning (I'm not advocating waterfall, just that you should still be able to loosely plan sprints in advance knowing that the contents of those sprints are likely to change are you approach them).

Teams can also have different objectives / responsibilities. At Atlassian many engineering teams have a responsibility to not just deliver new features but also maintain existing services, so our focus is split (I'm not necessarily saying this is a good thing) so trying to ensure have a healthy balance of feature work vs operations can be important.

I have worked in teams where there is a singular goal to deliver something and teams working like that behave and plan very differently.

There's definitely no "one size fits all" solution for sure, but my goal is to lean on existing data within the backlog to help future planning.

Welcome!

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

Quick Links

Find more posts tagged with

jira

agile

sprint

capacity