Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Burn Down Chart Not Showing Progress

My project's burndown chart constantly shows a flat red line. Is there something I have misconfigured or not had the team update a field in the User Stories? Any assistance would be greatly appreciated.

 

Thank you,

Tom

3 answers

0 votes

Are you estimating the issues with story points, hours, or another field?  (Note - not sub-task types, only the story level stuff). 

Is that the field selected in the estimation statistic for the board?

Are all the issues you expect to be burned down in the far-right column of the board?

1. We are estimating with Story Points.

2. The Estimation Statistic is Story Points but Time Tracking is Remaining Estimate and Time Spent. I think this should be moved to None.

3. Not all of the issues are moved to the far-right (Done) column yet.

Like Raphael Paes likes this

Update: The administrator changed the Time Tracking to None. Now the Burn Down Chart looks like this. Any assistance, is greatly appreciated.BurnDown Chart1.jpg

Looks to me like you are adding stories into the sprint (or adding points to stories in it) but never completing any.  Are you moving your stories into the far right hand column at all?

Nic,

Thanks for the reply. No I couldn't move the stories to the far right b/c I work with a gov't entity and user story isn't done until it goes through a through security scan. That being said, we deployed over the weekend and I have moved about half of the user stories to the far right (which is Production) for our team. This is what the Burn Down Chart looks like now. It's still looking messed up. 

2018-02-26_12-11-15.jpg

I'm not sure what's wrong with it, could you explain?

It now has the line falling on the far right, as you've marked some stuff "done", so it looks right to me.

Nic,

I am more accustomed to seeing Burn Down Charts like the example I am showing here. Perhaps, I'm missing a proper configuration in how I track User Stories or something?

Thanks for any insight.

burn down chart example.jpg

The burndown chart you would look like that if you had been moving the stories to "done" during the sprint.  You've moved them all at the end of the sprint and you've been adding points into the sprint during the execution.  The graph can only go on the information you give it.

You have to pay attention as Jira software does not start or finishes the sprint by it's own, you have to put and estimate the stories before the start of the sprint.

Hello, on my side I'm also facing similar issues.

 

See my two burndown charts attached. Why is it not possible to see the Guidelines Line on my chart?

And why is the Time Spent line on my second chart above the Remaining Values Line?

 

Thanks!

2021-04-05 14_04_58-Scrum Board - Agile Board - JIRA.png2021-04-05 14_04_20-Scrum Board - Agile Board - JIRA.png

This looks like you started the sprint with no issues that had estimates on them, then added issues with estimates into it, or added estimates to the items in the sprint.

As you started with a zero estimate, your guideline is there, it's just drawn over the x-axis - a grey line at 0!

Thanks Nic, 

is there a way to show the Guidelines properly now? Should I delete my Sprint and do another one?

Thanks!

The guidelines are being shown properly, if what I've described is what you did.

A new sprint, started after estimated issues have been put into it, would fix it, yes.

Hello so now that I created a new Sprint, here's the result i'm getting. We started working on the issues beginning of March. Is that the reason i'm getting a graphic like that?

 

Thanks!2021-04-06 08_40_42-Scrum Board - Agile Board - JIRA.png2021-04-06 08_40_29-Scrum Board - Agile Board - JIRA.png

Both of those are saying you added a pile of estimated issues to an active sprint on April 6th.

I am not sure why you have done this, it is of no help repeating the same thing that broke your sprint report before.  As I said before: A new sprint, started after estimated issues have been put into it

Ok, maybe I misunderstood. So what I need to do is to create a sprint where the Start Date is after the moment the estimation was done for all issues?

Because what I did now is to delete my previous Sprint and removed all the issues that were in it. I put all issues back to the backlog and they already have been estimated. However, my team started working on all those tickets on March 8 so this is why I put the Sprint Start Date to March 8. 

I recreated the Sprint and added my issues again.

No.  Forget the dates and historical work, they do not matter.  The process this stuff is designed to support is:

  • You have a backlog list of items
  • You should estimate them, at the very least the ones you are expecting or hoping to work on next
  • You rank them against each other, deciding broadly which ones should be tackled next
  • Once you have.a ranked list, look at the top of it - all the items at the top of the list should be refined enough that the developers are confident that the estimates on them are broadly right
  • Now you make a sprint (a timebox with a known end-date) and start taking the top ranked issues into it. 
  • You only take in the amount of estimate that you think you can realistically complete within your sprint.  
  • If you have items that can not be completed within a sprint because they are too big, then you need to do more refinement - break them up into stories that can be done inside a sprint (or make your sprints larger).  Or, you stop trying to use sprints, because your process is not going to fit with it.
  • At the end of the sprint, you can report on what you completed, and what you did not - that velocity should be used to inform how much you take into the next sprint.

The important thing here is that you start a sprint with a list of issues, with estimates, that you think you can do within the sprint.

Hello,

 

thank you for your detailed response. This is exactly the process I followed. This is why I don't understand why the Guideline (Gray line) is still flat and what I don't see the Time Spent Line (Green line). 

Like mentionned by another user in this ticket, I'm also expecting a graphic that has the guideline going down and seeing if my progress (time spent) is above or below the guideline. 

We want to be able to see if we are on track on the work that has been estimated. This is why we would like to have a burndown chart that is representative.

Did you start with a clean, un-worked on, set of issues?  I suspect that the moving around you've done on the existing issues may be getting in the way.

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

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

Events near you