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 …
Continue reading ‘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. InfoQ: Agile Risk Management.
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, …
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 …
Continue reading ‘Managing large stories on agile projects, our approach’ »
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 …
Continue reading ‘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 …
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