Michigan Agile and Beyond 2011

A couple days ago, I registered for the Michigan Agile and Beyond 2011 conference. A crew of TechSmith employees headed down to Dearborn, MI last year for the inaugural event. This will mark the second year of the conference and will feature speakers from across the region that work for companies of all sizes.

Personally, I’m looking forward to learning more about Kanban. The software team that I work on has adopted Kanban recently and we’re still learning how to use to its maximum potential.

The conference takes place on Saturday, March 12 and is only $79 to register during the month of January.

See you at the 2010 Michigan Agile and Beyond Conference

I’ll be heading down to Dearborn on Saturday for the 2010 Michigan Agile and Beyond Conference with some coworkers from TechSmith. If you didn’t know about the conference before, or you weren’t planning on going, now’s your last chance to change your mind.

Among the speakers will be Ron Jeffries and Chet Hendrickson, who I’ve been lucky enough to meet and talk with when they visited TechSmith.

Are you going?

Proper Units for Task Estimation

Yesterday during a planning meeting, some fellow developers provided rough time estimates for some features that have been requested by the business team. The estimates looked like the following:

• Create awesome feature X – 2 weeks
• Resize GUI component Y – 3 days
• Capture more meta information – 26 days
• Support better use of internet tubes – 4 weeks

Much planning and thought goes in to numbers like these. There are often many smaller tasks that comprise one of the estimates given. But out of any of those estimates, did any strike you as out of the ordinary?

It turns out that while those estimates might be spot on, they either don’t leave much or create far too much room for error. According to the Pragmatic Programmer, there is a lot of weighting determined by these numbers. Estimates given in weeks are often budgeted to be off plus or minus a week or two. Estimates given in days are often budgeted to be off plus or minus a couple days.

Therefore, the two week estimate is a shorter time span than the 26 day estimate, yet is given much more cushion room. Estimating a large task can be very hard, as a task that may take 26 days or 4 weeks almost screams that there are plenty of unknowns.

Here is what the Pragmatic Programmer recommends:

Duration	Quote estimate in
1—15 days	days
3—8 weeks	weeks
8—30 weeks	months
30+ weeks	think hard before giving an estimate

So what should have those estimates looked like?

• Create awesome feature X – 14 days
• Resize GUI component Y – 3 days
• Capture more meta information – 4 weeks
• Support better use of internet tubes – 4 weeks

Moral of the story: be wise when using units of time for estimation because product schedules depend on them.