I look at tasks estimates three ways. There's what I call "inside time", and "outside time", and "wall clock time".
My idiosyncratic "inside time" is: how much time will it take for me to code the task. This is my butt in the chair, typing on the keyboard. Including upfront learning time (if necessary), and running the code under the scrutiny of the debugger, verifying that it works to my satisfaction. For that place that I worked where we did unit testing (TDD-style, C#, NUnit, NCrunch... oh my, that was awesome, made unit testing -- dare I say -- FUN), it also included the coding for the unit tests.
My idiosyncratic "outside time" is: all the inside time PLUS all the time that I have to sit in meetings, stand up in the Scrum stand up meeting, fill out HR surveys and watch HR videos on <insert HR hot topic of the month>, go to my one-on-one meetings, go to interdepartmental meetings (usually because our team consumes some technology from another team). This time includes all the overhead time of being an employee in an organization. This is the time that goes in the task on the Scrum board. (NOTE: I find this to work far better than trying to adjust each team member's capacity to factor out that overhead.)
My wall clock time, which isn't idiosyncratic, is start-to-finish time. If I have a 1 hour (inside time) task, which after factoring in the overhead (outside time) is 2 hours... but it will take 5 days to go from start-to-finish to actually complete the task because it will be blocked periodically and has lower priority than swarms of crasher bugs and fire fighting drills. This is the time that the product owner and stakeholders actually care about.
I've been at places that expected estimates to be small, so tasks should be at the granularity of 4 hours. And management's expectation is that those estimates are within 10% of actual. I found those expectations to be unfeasible and unreasonable, but c'est la vie. Also creates a lot of busy-work overhead for spec'ing out all those micro-sized tasks. But that's what micro-management demanded.
I've also been at places that expected estimates to be just a rough ballpark, and no one got cranky if the "8 hour task" turned out to be 1 hour, or 16 hours. That helped not get bogged down in stressing over the tracking, and focus instead on the work.
I look at tasks estimates three ways. There's what I call "inside time", and "outside time", and "wall clock time".
My idiosyncratic "inside time" is: how much time will it take for me to code the task. This is my butt in the chair, typing on the keyboard. Including upfront learning time (if necessary), and running the code under the scrutiny of the debugger, verifying that it works to my satisfaction. For that place that I worked where we did unit testing (TDD-style, C#, NUnit, NCrunch... oh my, that was awesome, made unit testing -- dare I say -- FUN), it also included the coding for the unit tests.
My idiosyncratic "outside time" is: all the inside time PLUS all the time that I have to sit in meetings, stand up in the Scrum stand up meeting, fill out HR surveys and watch HR videos on <insert HR hot topic of the month>, go to my one-on-one meetings, go to interdepartmental meetings (usually because our team consumes some technology from another team). This time includes all the overhead time of being an employee in an organization. This is the time that goes in the task on the Scrum board. (NOTE: I find this to work far better than trying to adjust each team member's capacity to factor out that overhead.)
My wall clock time, which isn't idiosyncratic, is start-to-finish time. If I have a 1 hour (inside time) task, which after factoring in the overhead (outside time) is 2 hours... but it will take 5 days to go from start-to-finish to actually complete the task because it will be blocked periodically and has lower priority than swarms of crasher bugs and fire fighting drills. This is the time that the product owner and stakeholders actually care about.
I've been at places that expected estimates to be small, so tasks should be at the granularity of 4 hours. And management's expectation is that those estimates are within 10% of actual. I found those expectations to be unfeasible and unreasonable, but c'est la vie. Also creates a lot of busy-work overhead for spec'ing out all those micro-sized tasks. But that's what micro-management demanded.
I've also been at places that expected estimates to be just a rough ballpark, and no one got cranky if the "8 hour task" turned out to be 1 hour, or 16 hours. That helped not get bogged down in stressing over the tracking, and focus instead on the work.
Joel Spolsky Painless Software Schedules is a good read, but he says DO NOT READ IT. Instead he now advocates Evidence Based Scheduling. Goes to show that even Joel Spolsky can change his mind. ;-)
Will have a read, thanks!