Summary: Note: I am re-publishing this entry because a few weeks ago, I messed up and had the wrong link to the podcast. It directed you to a conversation about domain analysis rather than estimating. Several alert listeners have pointed this out, and I appreciate it. My apologies! And don't hesitate to keep me honest: jim.trott@netobjectives.com The correct link is below: Estimating in Lean-Agile Stories should be between a half day and 2 days. If we cannot get it down to a couple of days, then we don’t really understand the problem yet. This is especially true for new code and new features. Of course, there are code bases that require more than a couple of days, but these tend to be code bases that already have code quality issues. The big benefits of having stories that about 2 days in length are: Developers understand what to do before they start working on the code Management can understand the progress that is being made, by tracking the velocity of story burndown. You avoid thrashing and being overwhelmed by having too many small tasks, having to go back to the well to try to figure out what is next. Sometimes, teams are reluctant to give estimates, especially when they have been motivated by fear and they have been whacked when they give bad estimates. Metrics can be used as a weapon. And that is too bad, because in new environments and with waterfall methods, it can be really hard to make good estimates. That’s when we resort to rules like “double it and add 10%”. This can arise when management requires a certain fixed number of features be released according to a fixed release schedule, without knowing if that is reasonable. In such situations, the only variable is code quality: you get features that are released, but with bugs that then have to be fixed in future cycles (but that is in the maintenance budget, so doesn’t count against you.) Helping teams build better estimates Very frequently, the people who are tasked with estimating projects ask the Lean-Agile coach for help in developing better approaches for estimating. They know that this is a big problem. They want to do better, both to build their own credibility and to give management the ability to prioritize better. To help them, Rod Claar does what most Lean-Agile coaches usually do: ask questions that help them think (rather than simply giving answers). What have you done and how has that worked for you? Did you work hard? Could you have worked harder? How do you know it has not worked? Did you learn a lot? In what specific ways did you refine your process based on what you learned? If it is possible to jettison the heavy up-front analysis in favor of Agile analysis, that is best. If the business requires that up-front analysis, then perhaps the coach can help management take a middle path: do everything that they would normally do in an upfront analysis effort, but time box it and put iterations around it. Thus, do a Planning Game for a week, then do development for a month, and then look at what was learned and plan again. This gives the benefit of the iterative approach while not really costing the business any more – they still get a good reasoned set of requirements at the end of a month. And you can still give them a 6-9 month plan, but it is updated after every (30-day) iteration. To effect this sort of change in estimation, the coach has to have the conversation both upstream, with management, and downstream, with developers and available customers. And the conversation must take place fairly early, say in the Define stage – especially if the decision to go Agile is coming from the top. And, increasingly, we are seeing the need to go Agile coming from the top of the IT organization. Recommendations - Training by Net Objectives Agile Analysis Lean Software Development Scrum Recommendations - Reading Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott Music used in this podcast: “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnote
