Frank Carver’s Punch Barrel

We are currently struggling with how to integrate work on refactoring/simplifying/cleaning our product codebase with existing streams of stories and bugs. One of the tricky aspects of this is how to estimate and prioritise the cleanup work: how much is it worth, and how much time should we spend on it this iteration?

Martin Fowler has written about extending the idea of “technical debt” by including the concept of “interest”. Extra time spent on completing any given task compared with the time which would/might have been spent implementing that outcome on a cleaner system is effectively an “interest payment” on the “technical debt”. Noting an estimate of such an amount along with the elapsed time on each piece of work allows a relatively simple calculation of the total “interest payments”, and helps inform any decision to “pay off” the debt by refactoring, simplification, etc.

MF Bliki: EstimatedInterest

Interesting thoughts from Mana at “Geek Diva”

Geek Diva: Finding our target velocity without black magic

An interesting article, apparently based largely on the keynote from Agile 2008. Some clever stuff about estimation, averages, and the wisdom of crowds in the context of software development teams.

Gojko Adzic » Bulding smart teams

Estimation is a hard but vital process. Maybe an interesting parable would help?

Software Estimates and the Parable of the Cave » “Hello World” - The SlickEdit Developer Blog

Back to InfoQ again for an extremely practical and useful guide to estimation. Now I just need to get the company comfortable with the idea of estimation at all

InfoQ: User Story Estimation Techniques

I have recently discovered a new blog to follow: “notes from a tool user”. The author, Mark Levison has plenty of opinions on agile software development.

Standout recent articles include:

• Agile/Scrum Smells
• Test Driven Development vs “Plain Old Unit Testing”
• Estimation
• Tools, Tools, Tools
• Mythbusting - Collective Code Ownership