Logging Time and impact it has on Original estimate

Jason Donaldson June 27, 2017

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')

3 comments

Comment

Log in or Sign up to comment
Jason Donaldson June 27, 2017

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 July 31, 2017

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-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 27, 2017

>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 June 27, 2017

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-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 27, 2017

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 June 27, 2017

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-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 27, 2017

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 June 27, 2017

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-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 27, 2017

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.

TAGS
AUG Leaders

Atlassian Community Events