Sprint Burndown Chart does not show issues complete so Graph is wrong. Why?

[GameDev]

Hello, 

Can anyone help us with this? Its easier if you see the screenshot of the burndown chart and why it isnt working correctly? As far as we know we updated it correct (ie from ToDo to InProgress to Done during the lifetime of the 2 week sprint).

Many thanks for your help

[Nic Brough -Adaptavist-]

Are the "done" issues all in the very last (rightmost) column on the board?  Along with all their subtasks?

[GameDev]

Apparently Next-Gen Boards dont have the capability to view previous sprints already closed, only the current open sprint and the backlog. Unthinkable in other PM programs, im not sure why Atlassian removed this, unless im doing something wrong?

https://community.atlassian.com/t5/Jira-Software-questions/How-to-view-a-previous-sprint-that-has-been-closed/qaq-p/1017041 

[Jack Brickey]

what historic info are you seeking?

[Nic Brough -Adaptavist-]

Previous sprints were not mentioned in your original question, so I'm a bit confused.  But thanks to @Jack Brickey for answering that!

[GameDev]

Hello Jack & Nic,

Thanks for replying.

Sorry my bad, the sprint picture your seeing was from Sprint2 and were currently on Sprint4. To answer both of your questions is it possible to view previous sprints boards as that is the only way i can definitivly answer? Unfortunately, as i think me and Nic had this discussion before the team wanted extra fields "Complete" to be added (so the sprint went from ToDo>InProgress>Done>Complete. I know this may have messed the bar up but unfortunately i cant remember which sprint this system came in. ie> Some sprints were actually only ToDo>InProgress>Done on the board, so until i goto the actual board of that sprint and see when the change over happened i wouldnt know. It seems quite likely thats the reason for the graph not updating but i would like to confirm it. Is there a way to see board views from previous prints?

Many thanks

[Jack Brickey]

it seems you are trying to assess when (which sprint) your board changed and added the Complete final status by interrogating historical sprints. There is only a single scrum board and it represents any active sprint. If no active sprint the board is empty. This is not unique to NG BTW.

With that said, I’m trying to understand your true goal here. It seems you are not seeing the burn down behave as you are expecting and trying to figure out why this is the case. TBH, I don’t use NG much and certainly not for scrum activities so I need to refresh my understanding of how it behaves. It seems from the image above you are using issue count. Given this, whatever status is in the right most column, when you move an issue into that column I would expect the burn down to illustrate a decrement by 1 for that issue. I did a quick test on one of my instance and did not receive the results expected. I received a completely blank burn down with no red-line at all. However, given my lack of NG hands on experience I’m unsure if my expectations are misplaced or if something is wrong.

Maybe Nic has some insights here.

[GameDev]

Hello  Jack

We are new to Jira as you may have guessed however our previous experience with Sprints, the methodology and Scrum is advanced on MultiMillion £ project using Mainly the Microsoft suite (Excel and Dashboards to be precise) so moving over to Jiras functionality is a new experience for us all. Do you think we would benefit from Classic setup for projects then and not Next-Gen?

Also, i feel the original answer from Nic was correct.

I also think moving project setups will give us the same problem due to our methodology. If we dont move items which we use to track to the far right of the board then it wont work correctly in Sprint Burndown graphs. (ie> Miss the extra step we added)

I am in favour of abandoning the extra stage in the board and just using the Sprint Review meeting to move items back into a new sprint or indeed declare then truly Done. That way all the maths in the back-end done to generate sprint reports and charts will work correct. I think this may be the solution.

So in conclusion

Todo>InProgress>Done = Generate correct Sprint Burndown graph.

Todo>InProgress>Done>Complete = Will give us an incorrect graph because all team members when an item is complete move it to "Done" which is the 3rd stage. Items only move to "Complete" at the end of our Sprint Review meeting. In other words everything gets put to the far right of the graph only the day after the Sprint, no wonder it didnt work!

[Jack Brickey]

So a few things to unwrap here.

• should you move to classic - a bit difficult to answer TBH because there is so much to consider and w/o really knowing your business it is hard to offer an opinion. The best I can do is say that for my purpose NG hasn't, as yet, sufficiently met my SW project needs. Moreover, they are so different from Classic projects that trying to admin both is just extra work that I'm not excited to take on. Classic project are extremely flexible and powerful but with that comes quite a bit more admin challenge than NG. NG allows teams to get started quickly and not become overwhelmed w/ the complexity that can arise with Classic. I will go out on a limb and say that invariably you will hit some barrier in NG that you can't overcome at some point. Whether the barrier is just a pot hole or a chasm is unknown.
• Nic is right - Nic is always right ;-) and you can't go wrong w/ his input
• Crux of your issue - now it is clear to me what is going on here and you hit on it exactly. Your team is using Done (3rd) column and expecting that equates to "really done" in the eyes of Jira scrum board. "Really done" = the right most column ONLY. So all Done issues in your case need to move to Complete if you stick w/ the 4-columns you have today. As you stated, you should reassess why you have Done and Complete. If there is truly a sound reason for having the two 'done' statuses and you wish them both to be "really done" then definitely move to Classic for this one project and map both Done and Complete into the RH-most column. My advise - be careful with multiple done status that seem to convey the same thing. Where I do use two done categories include: things like Done, Cancelled or Resolved --> Closed in which case the dev team sets to Resolved and the 'customer' gets the final say of Closed.

hope this helps.

[GameDev]

Hi Jack

Nic mentioned this a while back but we wrestled because i have a bit of a pit bull terrior of a team, grown men but more akin to babies! One minute want one process, next minute want another, then go back on what they suggested and said can we go back to the original thing we asked for - like a dog chasing its tail! I think this in the process broke the sprint burndown as i had thought Jiras backend maths would take "Done" (and leave it named that way regardless of it being the 3rd stage and most at the right or the 3rd in a line of 4 and "complete" being the last item. Nic advised against this. So it seems the right hand column is the maths integer to link the graphs and not a text_string as i thought it might be (leave it named as Done for that purpose).

I think we are going to remove the "Completed" column completely and the team agree this time. None of our burndowns was wrong on Microsofts Scrum suite we used but they broke on Jira and it seems its not Jiras fault.

In regards to cancelled, resolved etc... your version of our "Complete" this can just be done in the Sprint Review meeting. Really a giant 60inch screen with all the team reviewing it on a friday afternoon. The "Done" column (kept at default Jira NG values) is basically the same list we will use. Anything that needs to be re-opened or amended can be put onto the next sprint in ToDo > Added to backlog and we can close the sprint.

The MOST IMPORTANT thing is we get a graph that works on burndown detailing exact days items were knocked off the backlog, which is the most important thing when youve got a thousand items for the full product to go through.

Im glad its the weekend :-)

have a nice one.