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

Sprint completion on two columns?

Gabriela G

Hi all,

1. Can a Sprint completion be based on 2 columns?

E.g our last 2 columns are Done (which does not imply e deploy) and Deployed to UAT, each having tasks with homonym statuses. From our perspective both are "Done".

Thus, can Jira consider task from both columns as completed? (We don't want to map both statuses on a single column)

2. We use an aggregate board, with tasks from many projects. In our backlog we have a pool of certain task. Out of those we select only a few in the Active Sprint. When we complete the Active Sprint, the "Incomplete" sums up the ones from the Backlog as well. Any idea why? And how can we prevent that?

Accepted answers

Nic Brough -Adaptavist-

No, Jira Software only looks at the last column for "done". If you want several status to be "done", you have to put them all in the last column.

When you say "tasks", my guess is that your tasks are sub-tasks. These move through the board with their parents, not separately.

All comments

Nic Brough -Adaptavist-

No, Jira Software only looks at the last column for "done". If you want several status to be "done", you have to put them all in the last column.

When you say "tasks", my guess is that your tasks are sub-tasks. These move through the board with their parents, not separately.

Gabriela G

Thanks for your answer. It clarifies my first question.

As for the second, indeed I caused confusion. By task I mean user stories - the parent.

They are visible in this aggregate project (where we have the sprint board) only when they are in status X, and by default they show up the Backlog. In the planning we drag a few of those in the Active sprint. Let's say we have 10 items in the Backlog, we drag 4 in the Sprint, we close the sprint without finishing those 4, and the result is that 10 are falling. I would have expected only 4 would fall because we committed to 4, not 10!

So what are we doing wrong?

Nic Brough -Adaptavist-

I am sorry that this is so so late, I completely missed the updates.

I can't tell if you are doing something "wrong". Part of the idea of Agile is that proscribing process is not the way to go, and you should adopt processes that work for you, not ones based on ideologies.

In your comment here, I would expect the failure rate to be 4 as well. You drew 4 into the sprint, failed 4, and the other 6 are utterly irrelevant to the sprint because you did not add them to it.

I think we need to look at why the other 6 are "failing" when you are not adding them to the sprint. Could you look at where they appear in the backlog, and/or if they are appearing in the sprint?