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!
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.
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!
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!
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!
The draggable line I described would support you. It's mostly cosmetic though - Jira already supports what you need by allowing you to put "in test" in the last column so your issues count as done when they reach in-test. I just think the many column solution is a cosmetically better view for some teams.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events