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

Reading (strange) Greenhopper burndown chart

Aquarius

Dear community,

I am using JIRA with SCRUM type of board. Sprint is in progress for some days, not really much work is done so far, but ...

Burndown chart looks strange to me, it misses the ideal burndown. Is there anything wrongly configured or?

Please have a look at the attached image...

Thanks for your help in advance,

Aquarius.

Accepted answers

Renjith Pillai

There is nothing wrong in that graph.

The red line continues to be straight as there is no burn down
The burn up happened because the remaining estimate has gone up as Ahmand said.
The ideal line (Guideline) is missing because the estimates were added shortly after the starting time of sprint. The ideal line is there, since it starts at zero and ends at zero, it is not visible.

All comments

MatthewC

is you team recording time spent?

AhmadDanial

Hey there, Aquarius.

One of the initial assumptions that I have when I see this is that you might have added more issues into the Sprint when it is still ongoing, causing the Remaining Time Estimate to go up before it gets burned down again.

Warm regards,

Danial

Renjith Pillai

There is nothing wrong in that graph.

The red line continues to be straight as there is no burn down
The burn up happened because the remaining estimate has gone up as Ahmand said.
The ideal line (Guideline) is missing because the estimates were added shortly after the starting time of sprint. The ideal line is there, since it starts at zero and ends at zero, it is not visible.

Aquarius

@Matthew: how can I know that?
@Ahmad: correct, but I still miss the ideal burndown.

Thanks again,

Aquarius.

Renjith Pillai

Read my comment above regarding ideal burn down.

MatthewC

Hi Aquarius, you just need to check the recent updates and check that they are logging work (Work logged field). I'd say that they aren't which is why the line is flat. the odd jumps are probably because someone has changed data in some of your issues

@Renjith is rigth, in that it looks like you've added the data to the sprint AFTER you started the sprint. that way the hours at the start of the sprint =0 and the line goes from 0 -> 0

Change the sprint start date to Jan 31 and you should get a better line.

Also, get your team to pull their finger out and start logging some time! ;-)

Franz Schmidt

Hi, I have a simmilar problem with the ideal line (guideline). It is missing and it is NOT because I add stories after the sprint started.

If I look at the Sprint log file below the burndown chart, I can see that Jira Agile used the time I 'created the Sprint' as the 'Sprint start' time. So, in this case I created the sprint at 12:00pm before the Sprint planning meeting. The Sprint backlog got filled during the Sprint planning meeting and I 'started' the Sprint at 03:00pm after the Sprint planning meeting. Burndown chart looks similar to Aquarius picture above. Only difference is there are no peaks in mine.

This is a bug. Time should only start ticking when I hit the SPRINT START button. Where would you suggest to file issues like these? best,

Franz Schmidt

wow, this forum is on fire!

I found a solution to avoid the problem with the missing guideline:

Always set the start date of the sprint to a future date even if this means that your sprint technically is shorter then the time planned.

We do sprint plannings monday afternoon but due to a whole lot of stuff to prepare I (as a scrum master) am starting the iteration tuesday afternoon in jira agile. Since I set the start date to tuesday afternoon I get the correct represenataion in the burndown view.