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 can I change the settings for the burn-down chart?

Benea Andrei

Specifically, the issue I'm having is that I do not get reliable results from the burn-down chart, simply because it will only subtract story points IF the tickets in question are marked as done.

This might be viable for other people, but where I work, a ticket is only DONE when it's deployed (successfully) to production. Applied to the burn-down chart, this means that I can only see progress when everything is already deployed to production.

So, I would specifically like to have the option to CHANGE the status that the burn-down chart considers to be eligible for subtracting story points. I believe the board should be able to also handle situations where tickets return from testing and therefore the points go up again.

In my opinion this is the ONLY viable way of using the burn-down chart. I have seen a lot of "simple" solutions like moving the status of "testing" tickets in the "DONE" column, just to trick Jira. This is not a solution and it's definitely not "simple" as it apparently requires the creation of a second or perhaps third board.

Thanks for reading and the potential positive reply!

Accepted answers

Nic Brough -Adaptavist-

Welcome to the Community!

I'm afraid this is not what burndown on scrum boards are for. They're built to support off-the-shelf Scrum processes, which have a simple single definition of done, and you do not draw testing back into a sprint without treating it as scope change.

This is going to sound like "you're doing it wrong", but that is not my intention, it's about getting the tool to work for you because your process is not what it is built for.

I'd look at the team's process and change their "definition of done" so that it does have "done = last column". It's quite likely that your team doing most of the work has no control over "it goes to production", and their board should not be considering stuff they cannot do. So maybe move to having their "done" be "ready for production".

Then, as you've already mentioned, have a second board for tracking everything overall.

All comments

Nic Brough -Adaptavist-

Welcome to the Community!

This is going to sound like "you're doing it wrong", but that is not my intention, it's about getting the tool to work for you because your process is not what it is built for.

Then, as you've already mentioned, have a second board for tracking everything overall.

Benea Andrei

OK, I can understand that, but at the same time I believe it should be configurable to fit everyone's needs. So even if the way we are doing it is wrong, it is simply wrong because you do not offer any support for other workflows.

Moreover, why have two boards when you can have just one......

At least that's how I see it.

Anyway, thanks a lot for the feedback, I appreciate it!

Nic Brough -Adaptavist-

Personally, I don't think having a drag-left done column (a line you could drag left across the board to define the line between not-done and done) would be much of a problem, it would still support Scrum fine, especially if you had a "collapse" so people could make it look exactly like Scrum again if they wanted to. It would support those not doing Scrum's "definition of done for my team" and those who are with little complexity.

The only problem with having that is that multiple done columns means people have no reason to move between done any more. An issue in the done-but-not-last-done column by definition needs no more work!

Benea Andrei

In my opinion, this is a very simple matter that does not actually affect anyone, if they don't want it.

Let's say we have 4 statuses:

Assigned, in work, in testing, done.

What I want is a "switch" of sorts that will allow me to configure the burn-down chart in such a way that it starts subtracting points once a ticket reaches "in testing". That's it, nothing more. What happens afterwards is not important; as soon as a ticket goes through that status, it will either add or subtract points, depending on the direction.

That would be, the diplomatic way of solving such issues. Offer the User the option to set up his workflow just as he wishes. I believe that is, or should be, the main feature of Jira.

People work in different ways and it is my strong belief, we still live in times where we can make the software bend to our will, not the other way around. :P

Again, thanks for the replies, I will try to find a workaround!

Welcome!

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

Quick Links

Find more posts tagged with

jira