Logging Time and impact it has on Original estimate

[Jason Donaldson]

I use Time logging against Original estimate to give me an hourly Burndown chart, so the value is earned immediatley (as opposed to waiting untils it's 'Done')

My discussion point revolves around the impact logging time has on the remaining estimate, and if that estimate is too small what are peoples psrference as to how to reflect that underestimating?

For example if you have a 4 day estimate, and a resource has spent that already, but has 2 days of actual work left to do? Do you create a seperate task for the 2 days, and flag it accordingly so you can assess how many underestimates have been made at the end of a sprint?

Or do you up the estimate? What are the advantages of doing this?

On the flip-side of this if a task is finished early and 2 days are left on the estimate, how is this earned? (this may be a simple one as I think you can configure for the full value to be earned when its moved to 'Done')

[Jason Donaldson]

A slight amendment: I have suggested we might change the original estimate above, however should it actually be the remaining estimate that is updated, or both Original and remaining?

[Danny Fitzgerald]

Persoanlly I just update the remaining estimate.  I haven't used the Jira charts however so not sure what the impact is on those (I export to PowerBI and have built my own charts there).

[Nic Brough -Adaptavist-]

>Do you create a seperate task for the 2 days,

>Or do you up the estimate?

Neither.  The original estimate stands as "how long we thought it would take".  The time logs show "how long it actually took". 

Changing the original estimate is the wrong thing to do because we need to know what the estimate was, and logging elsewhere disassociates the actuals

[Jason Donaldson]

But then that impacts the burndown, work pie chart and overall dashboard information

If you don't do something to highlight the overrun how do you know cumlativley how much work is left in the sprint?

(well you do know, but it's not visible anywhere)

[Nic Brough -Adaptavist-]

No, that's the point, it makes the burndown and other reporting work correctly - they tell you what you estimated and what you did.

[Jason Donaldson]

In my mind the purpose of the burndown is to show progress and what is left to do. We want to work to 0 hours reamining by a certain date. If you then historically look at the burndowns by taking your suggested route every sprint looks like it has been a success

[Nic Brough -Adaptavist-]

Yes, that is what a burndown is for.  It's also trying to show you projections on how you are doing, and when the sprint ends, it can tell you how accurate your estimates were. 

If you go changing estimates or logging time outside a sprint, then by definition, it can't show you any of those numbers.

[Jason Donaldson]

so we a sprint of 10 days for example. We burn 10 days, therefore looking at the dashboard we have nothing else to do, as we've achieved our goal. However, we still have tasks to complete to make this a 'shippable' product. Where are these tasks avaialble to see for stakeholders/PM's?

[Nic Brough -Adaptavist-]

That's up to you really.  You appear not to want to track them in your dashboards and sprints, so I'd keep them separate and put them in a different project.  Or use an issue type you exclude from your board and sprint.