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 🙂
New release (GhostDoc 1.3.0 Beta) of very small and very useful documenting add-in for VS.NET. It is a good time saver, and with new features methods documentation should become even simpler. I use GhostDoc daily and it’s really rocks! Check it out!
Dave W Farthing’s Software Project Management page provides links to all kinds of project management resources. Link on TargetProcess is there too!
I’m really impressed by new features in ReSharper. The most exciting: NUnit integration, VS2005 support, Simple template creation and ASP.NET support. JetBrains rocks.
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%… 😉
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.
If you are new to Dependency Injection, this article may help. It contains explanations and real world example about the nature of DI. It compares code without DI, and code with Spring, PicoContainer, HiveMind and XWork implementations. Also there are several good links at the end.