Burndown chart is not updating

[Raju AD]

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?

[Nic Brough -Adaptavist-]

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

[Raju AD]

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...

[Nic Brough -Adaptavist-]

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)

[manuel.bedacarratz]

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?

[Nic Brough -Adaptavist-]

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

[msp]

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. 

[Nic Brough -Adaptavist-]

@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

[Nic Brough -Adaptavist-]

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.

[Kunal Sanyal]

Just 1 point about the Capacity Planning and Velocity - It think these two are used together to understand how much work the team can take in a Sprint during the sprint planning. Only Velocity can be tricky.

"I want to adapt Agile" and "I am Agile" are two different thought process or "Mindset" in Agile terminology. Shifting from one to another is a big challenge. I think from where this question came up is from higher management perspective. They all want to move to Agile but are not willing to change their mindset. They want a progress report on how things are moving, may be weekly. There are people who are not interested on the outcome of each Sprint, but are more inclined towards how much progress is made towards the end product on a daily/weekly basis. That's the pain point.

[msp]

Appreciate your response, and agree and to quote you that "Capacity Planning and Velocity - It think these two are used together to understand how much work the team can take in a Sprint during the sprint planning" - but you later point out that management needs progress on a daily/weekly basis as a pain point. 

To me, who as a developer as well as a manager getting "how much work the team  I as an individual developer can take" has helped me at getting good at estimating future tasks (called scientific method).  Pragmatism, dictates to get better at estimates one needs to try how you as a developer are measuring up. 

Management could care less about a few days here a and there.  If you have practiced enterprise software development you'd know that your sprint estimates hardly translate to real calendar time delivery dates.  The estimates which are relative rather than absolute based on the magnitude of the Tasks needed for "how" something gets done need to be translated into time so that individuals can do better at relative estimation.  Not many developers even have a clue how to estimate.  This fundamental assumption that JIRA sticks to without providing the individual developers insight into how he/she is doing in my opinion an abject failure.  There is a reason other tools allow teams to do more.