As anyone who has ever done sprint planning will tell you; estimating the time a task will take to complete can sometimes be a risky, confusing and sometimes arrogant or embarassing business.
Unless you have absolute equilibrium in your team, ie everyone is at the same level and can perform at the same pace, you’ll often come across situations where a developer will say:
“That will take 3 ideal hours!” and sit, smug in the knowledge that they can do that task in 8 hours (or more, generally. Don’t forget Boyle’s law).
“Um, ” says a small voice, “I think it would take 6 hours.” The new team member, green as the grass on the other side, but sharp as a tack pipes up. “I don’t know how to attach the hoo-hah to the wot-not, I’d need to research that.”
“It’s easy!” says smug developer, “You simply wangle the wand at the warlock and insert the key of truth.”
“OK, ” retorts the green guy, “Didn’t I read in the out-of-date wiki entry that there is three factor authentication on the key of truth? I’d need to read up on that before I started the task.”
“Pah”, says smug developer, “Then I should do it.”
and thus fails scrum. Allocating tasks during planning is, sometimes, a neccessary evil, especially if you’re up against an arbitrary deadline as we often are. However, if you do find yourself having the luxury of being able to swarm on stories, or pick any task from the board, then you should and you should usually pick one you have no idea how to do. This’ll give you a chance to do some on-the-job learning from your peers and mentors. Consider this though:
“It’ll take me six hours, but I’ll have it done by the end of the day tomorrow, ” says green developer, “I don’t have any other responsibilities at the moment”.
“Ah, yes, ” says old man smug, “I am the scrum master (yes, yes, quiet down – sometimes you DO need to do both) and I need to the new business team with some issues and also I have to record some training screen casts, so I won’t be able to have it done for another three days, even if I started it now!”
So, as you can see, it’s all swings and round abouts. The rules (or guidelines) I’ve heard many times state to go for the higher figure. With a dash of common sense obviously, if it’s more than double the amount of the lowest figure, then you’ve got other problems. Always err on the side of caution I say, but that’s up to you.
Why is this important? You need to be consistent with the blocks of time/effort/whatever you estimate with. Ideal hours seems the best way to go about it, but don’t, whatever you do, start referring to six ideal hours as a “day” it’ll just confuse the issue. Six ideal hours is just that. It might take one day, or it might take six. However long it takes in real time, make sure your estimates in ideal times are as accurate as they can be. It’ll help in the long run as you’ll get better at estimating, better it getting it right sprint after sprint and it’ll help you eliminate the waste. Time holes that suck away your resourced hours will be highlighted because by the end of the sprint, you’ll not have “spent” the ideal hours, yet you’ve pissed away a two week iteration. But at least it will show you where your problems lie.