Frank Carver's musings about software and life
I’ll say up front that I have some major issues with the idea of estimation in agile processes. There are plenty of alternatives to traditional time/manpower estimation which are at least as useful in delivering real, useful results.
However, if you are working in a context which values estimation, Adrian Wible has some interesting points about whether it is wise to re-estimate incomplete stories each iteration
Adrian’s Tech Blog: The case against iteration based re-estimation.
There are lots of approaches to estimation for agile projects, but not all of them include estimation of risk. Some approaches deliberately ignore risk, preferring to work from hindsight and averages.
For the others, a consideration of levels of risk for each estimated story or task seems a good idea.
Anyone who has worked with me in the past will probably recognize my standard response to vague or unclear requirements – “how will I know when I’m done?”. I use it so much becuase the simple trick of changing viewpoint to view work in terms of acceptance criteria is key to enabling sensible discussion, estimation, planning and development to begin.
Mark Needham has been considering similar issues, but rather than using the technique to clarify requirements so a pice of work can enter the development process, he looks at how to decide when to remove it.
In theory, an agile story is a simple and obvious thing with many purposes. A description of some desired usage; a token for discussion; a prompt for acceptance tests; a grain around which to gather more detail. In practice, a story can sometimes be more like a traditional feature requirement, or more like a delivery contract. In these cases, estimating, developing, and delivering the story can provoke problems, risk, and conflict.
One such case is when a story is too large for comfortable estimation. Commonly this arises when a story is driven by a desire for a feature or sweeping change – something easy to give a name to, but complex in its detail. We have faced at least one of these most iterations.
Bill de hÓra discusses some approaches to tackling such large stories in a recent blog post:
Bill de hÓra: Managing large stories on agile projects
In our team we typically tackle the problem slightly differently. The items on our progress wall are represented by brown A5 envelopes, each with summary information (title, id, estimate) written in large, friendly letters on the outside, and an accumulation of detail (notes, time spent, diagrams, etc.) inside. To stop the contents falling out, the envelopes are all placed on the wall with the opening on the side.
Why do I mention this? We use a quick of this to deal with large stories. A story too large to estimate and develop on its own is represented by an envelope with the opening at the bottom. This implies that such stories can not accumulate detail of their own, but only reference other stories. We split the large customer story into several internal stories, estimate, annotate an develop them independently, but do not consider the main story complete until all the component stories are also complete. To show the relationship we write the ids of the component stories on the outside of the “vertical” envelope.
This approach seems to work. Stakeholders still have visibility of the status of the large story, and the development team is free to implement the component stories in parallel or in sequence, in whatever order is most effective and efficient.
In our team we have found a tendency for the time spent estimating stories to creep upward. More and more design seems to be considered as we work through the stories. While this is a very valuable way of sharing information among the team, it is not a very effective way of estimating.
Akshay Dhavle has written a brief blog post reminding that sometimes, all that is needed is a simple “small, mediun or large” estimate. Business Analysis: Can’t negotiate size… and a good thing too
Nice little post highlighting the need for value information along with cost estimates.
Don’t worry about how valuable it will be, just tell me how much it costs?
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.
Interesting thoughts from Mana at “Geek Diva”
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.
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 
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: