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