Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,293,501
Community Members
 
Community Events
165
Community Groups

Burndown chart is not updating

Hi,

In one of our Project, we are using Time Tracking, we have few issues assigned to Sprint and logged the effort. But when i try to generate the Burndown Chart against Original/Remaining Time Estimate, the graph is not updating (eventhough there are some log values entered for the isseus in that Sprint).

Can some one sugeest on this, y the graph is not updating?

1 answer

0 votes

Are your issues with logged work in the "done" column?  (Last one on the right, may be labelled differently to "done")

Hi,

is it is mandatory to have all the issues in the last column(Done) of the board to generate Burndownchart for Active Sprint? I am new to Agile..so...

Yes.

In Scrum, you can only burn down when the story is done.  To be done on a Jira board, it has to be in the far-right hand column, and fully complete (it's nonsense to claim an issue with open sub-tasks is done)

Can't you set it in a way so that the burn down happens in a previous state? Maybe in setting you can change this?

Like msp likes this

Burn-down happens when an issue enters the last column on the board.

Like gfoidl likes this

So how is one supposed to see daily progress while tasks are being burned down?  I guess folks should just expect work will magically get done once tasks reach done?  

Again, time to fire up that excel spreadsheet keeping track of time spent.  BTW, whats the point of having "Capacity Tracker" add-ons if I cannot get a daily burndown chart until the task is done?

Agile says tasks have to be between 1-16 hours, so if the devs have 4-6hr/day of capacity.  I will not know how the sprint is progressing collectively across various tasks.  Other tools do not do that. 

@msp - you have not grasped how to be "agile".

Using a spreadsheet and looking at "daily burndown." screams "not agile".  I think you might need to take another look at your processes

One of my colleagues pulled this up as an example of me being terse and unfriendly today (I'd prefer "grumpy" - it hauls me up on a wider range of writing and tone I would like to improve on) 

I'll try to describe what I'm getting at in a better way:

The focus in Agile is on "delivering good stuff that does what people want it to, and does it well".  It's not focused on "progress".  

But progress does matter, it has uses.  Jira Software provides Scrum and Kanban boards which are strongly aimed at supporting both of those ways of working, with some flexibility to work outside their "pure" definitions.  Both of them are mixed up with "Agile" because they are both a very good fit for it, but they pre-date it!

Scrum and Kanban, despite having similar boards, recommending that people share and collaborate, focus on getting it done, etc, work on very different principles when it comes to planning and reporting, and (in my opinion), capacity planning.

Scrum is all about the "time box", everything is done inside a time box and that's where you measure it.  Kanban is all about "throughput". Each card is the same "size", so the question is just "how fast are we getting through the cards?"

Anyway, I'm not expecting any of that to help a lot, but it might frame my attempt to improve my responses:

 

>So how is one supposed to see daily progress while tasks are being burned down? 

Daily progress is irrelevant in Scrum.  Progress is measured between the start and end of a sprint.

 

Daily progress is irrelevant in Kanban.  Progress is measured by grouping cards by goal and looking at how many of them are getting done over whatever timeframe you choose.

 

>I guess folks should just expect work will magically get done once tasks reach done?  

Yes.  Not "magically" though, it's the other way around.  When the work is complete, the teams move it to "done", to say so.

>BTW, whats the point of having "Capacity Tracker" add-ons if I cannot get a daily burndown chart until the task is done?

To try to estimate capacity. 

But, again, for Scrum, capacity tracking is about the timebox.  You should be using the velocity to look at what the current capacity is for each sprint.  Daily is useless, you need to be looking at each sprint.

Kanban is again, more simple.  Look at the throughput over a few weeks.  If work in > work out, your capacity is too low.  If work in < work out, you have a high capacity.  Ideally, your work in : work out ratio should be exactly 50:50 but that just doesn't happen in real life.  Monitor your control reports and push towards 50:50, but accept that it's going to vary.  Worry if the variation is large.

>Agile says tasks have to be between 1-16 hours,
Mmm, again, not "Agile" directly. Scrum suggests it, but the actual "rule" there is "a story has to fit within a sprint".  1-16 hours works well with the "default" sprint length of a fortnight, but there's nothing wrong with having a story that clocks in  at 560 hours estimate - it fits in the sprint, but leaves no room for anything else.

> I will not know how the sprint is progressing collectively across various tasks.  

For me, this is the biggest question.  Why?

Why are you looking at the details of a sprint in progress?  The point of a sprint is thay they show you where they got to at the end of it.  It's supposed to free you up from having to think about it.  Look at the delivery, not how they get there.

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