Jul 29, 2005 / Effort Units in Agile Development: Time or Abstract?

0 comments

Team velocity and effort could be estimated in any units in Extreme Programming. For example, you may use melons, iPods or abstract unified coins. But vast majority teams still use days or hours. They are just natural and usual. Everyone knows what a 'day' is, but I want to see how you'll describe what 'melon' effort unit means to customer.

While time units are natural, they have two hidden problems. Estimates may look precise and this will be false precision. For example, "I think this story will take 48h". "Really?". "Yes, we should create UI and some complex business rules. It will take about 48h".

The other problem is a 'hidden safety' that is 'in blood' of many PMs. If you estimate in time units, you almost always will add some safety to estimated effort: "There are some unknown areas in this story. It may take additional 2 days to resolve. Or maybe 3 days? Let's get an average and add 2.5 days".

These problems could be avoided. The rule is simple: Make aggressive estimates and round up all numbers to days and a half. For example, 42h will be 40h, and 7 hours will be 1 day.

And there is one advantage in time units - you could easily compare estimated effort vs. Actual effort. Such information is just useless on personal level, but helpful on team level. Let's say, team performance for latest iteration was 20% higher than initially estimated, so all previous estimates for open user stories may be reduced by 20% (sure, you should be careful with numbers).

Use time units with care. It pays-off :)

posted by Michael Dubakov @ 7:44 AM