Estimating in Lean-Agile (and a mea culpa)

October 17, 2006 — Posted by Jim Trott

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:

Listen to the podcast 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

Recommendations - Reading

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at https://www.netobjectives.com/

Blog Type: 
Podcast
Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Jim Trott

Jim Trott is a senior consultant for Net Objectives. He has used object-oriented and pattern-based analysis techniques throughout his 20 year career in knowledge management and knowledge engineering. He is the co-author of Design Patterns Explained: A New Perspective on Object-Oriented Design, Lean-Agile Software Development: Achieving Enterprise Agility, and the Lean-Agile Pocket Guide for Scrum Teams.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban