Effort Units in Agile Development: Time or Abstract?

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 🙂

Agile Adoption

Interesting stats from Methods & Tools poll on question: “At what stage is the agile approach (XP, Scrum, FDD, …) adoption at your location?” (232 participants):

Not aware – 26%
Not using – 16%
Investigating – 14%
Analysed and rejected – 3%
Pilot projects – 4%
Partial implementation (adoption of some agile practices) – 17%
Partial deployment (some projects are using this approach) – 12%
Deployed (all new projects are using this approach) – 8%

It seems Agile approach has enough space to grow. About 60% of participants do not use agile development at all (note that 3% rejected it), 30% adopted agile development partially and just 8% use it as a mainstream process.

Looks like agile development overcame early adopters phase. But I wonder about that 3%… 😉

Ruby on Rails and J2EE

Interesting comparison of Ruby on Rails and J2EE. Author shows that J2EE application may be quite similar to RoR application (well, if you use Struts and Hibernate instead pure Servlets & EJB :). But code base of Ruby app is much more simpler and cleaner, and there is no XML configuration files!

Good news for C# lovers is that MonoRail project provides something similar (with Ajax support!). Promising, but I don’t like the idea to use NVelocity instead ASPX engine – component model works better for me.