Day 10 of 100 Know Why and How to Estimate

May 4, 2013 — Posted by Al Shalloway

 

 
I've been hearing two disparate views of estimation, and it does feel "camp" oriented.  The Scrum camp doesn't question estimation but is looking for better ways.  It takes much more time than it feels it should.  The reason for this feeling is that it takes much more time that it should.  Planning poker is useful in some situations, but for the very reason it is effective in some, it is very inefficient in most. If you need to get folks to talk, use Planning Poker.  Otherwise, there are two other methods that are much more efficient and just as good or better. These are James Grenning's Planning Poker Party and Steve Bochman's Team Estimation (from our Lean-Agile Pocket Guide for Scrum Teams and Lean-Agile Software Development: Achieving Enterprise Agility on our books page). Both are much more efficient because they use relative estimation (i.e., you first compare the stories/features with each other, making similarly sized groups) and then you assign them values.  
 
If you are in a maintenance organization, planning may be unnecessary.  But if you are wanting to plan out multiple releases and take advantage of team-members whose skill set/abilities/experience is in high demand because few have it, estimation is often essential.  The mantra of "no estimation" seems to me to be a reaction of inefficient methods in the Scrum camp and an over-enthusiasm for the Lean mantra of eliminating waste from the Kanban camp. Actually, I don't like "eliminate waste" as a Lean Software Development mantra.  It is too easily confused and taken up by folks who aren't really clear what waste is.  Not all planning is waste.  Not all estimation is waste. It depends how you do it. 
 
I believe one must look to the stakeholders to truly see if estimation must be done.  In many situations it doesn't need to be done for them.  In some situations it is actually useful for the team.  If teams are wanting to not do estimates because of what management does with them, then we have a problem between management and teams.  Just avoiding the estimates doesn't solve the problem.  Always go to what you are trying to achieve and why when looking at practices you are undertaking.  If estimation is taking more time than it's worth, see if there are more efficient methods than what you are using.  Don't throw out the baby with the bath water. 
 
Al Shalloway
CEO, Net Objectives
 

Take the 100 in 100 Challenge. I'm committing to add one entry each day.  I'm asking people to accept the challenge of reading them.  If you accept this challenge, please enter a comment on the blog that started it all and tell me why you are taking up the challenge - that is, what you'd like to learn

 
Author: 

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.


Comments

Sorry this is a repost w/ some extra info. but I'm the author of the words, though not the idea:

I participated in an agile-scrum group that implemented much of these lean methodologies. This department was able to double programmer productivity almost immediately—but there was some temporary stress increase as the change from waterfall to agile was made—they were able to produce a User’s Guide for each feature while the programming and QA was happening, and they were able to release features most needed by customers in a truly agile and quick manner. They accomplished this by the following practices and some others:

An analyst prepares some ideas for a project’s features and then schedules a meeting (Feature Blitz) where all the development team [domain expert(s), programmer, code reviewer, SQA engineer, the analyst, and any manager that really wanted to attend] decide the features needed, their specs, their implementation, the proposed order they will be coded and list of dependencies, breaks them into iteration-sized mini-projects, and at the end of the meeting assigns people to each of the above roles for each mini-project. The specs are the notes and digital photos from this meeting. Next each member of the team enters estimates of hours for them to finish their role’s work for each iteration or mini-project. The managers, in Iteration Planning, then swap around any resources or mini-project to maximize the use of everyone’s time, keeping in mind that changes may require the new team member to meet with the analyst or others to get up-to-speed on what happened at the Feature Blitz and that the new team member may not be able to do the role’s work as fast as the one who helped decide the particular implementation in the Feature Blitz. Next there is a commitment meeting where the development team (the four roles besides domain expert) commits to their deadlines even if they have to do overtime, which rarely happened because people became good at estimating their work ability. Simultaneously during an iteration, the analyst writes the User’s Guide, the QA engineer wrote a test suite with corner cases and exceptions that programming may not have thought about, the programmer and code reviewer discuss the details of the implementation and do the coding. Obstacles and progress were discussed frequently among the whole team and communicated to management and other stakeholders. QA tested each code drop so a programming path that wasn’t going to work was caught quickly and little code had to be thrown out. QA had enough time to do their job properly and checked how the feature functioned with other features. Analysts, QA, programmers, and domain experts generated other enhancement ideas not only for the project, but for other projects as there was more time for exploratory testing, prototyping, and thinking about the entire product/program. At the end of the iteration, the released product was more closely bug-free than the waterfall methodology. Lastly, QA had test suites that could be assigned in the future to other QA members or customer support for re-testing prior to each product/program release.

Sorry, I did not have time to explain fully as I've got work to do before I go home, but while we did an estimate on the entire product, [Cardiology software that was a patient record, drug-drug interaction, prescription sender, billing, ECG and other device integration, etc., etc., that is, a big product] we did not do any planning poker game or variation ever, but had ACCURATE estimates by using the Feature Blitz as our method, meaning the one who was going to program the feature gave their estimate after domain experts and others (QA & Analysts) all mentioned ramifications of the code changes.

In two and a half years (including when we first started our scrum-agile-lean hybrid), we were only later than "a single day" on one sprint and less than a day late on three sprints (once was due to hardware load testing that uncovered a need for a hardware change). All other sprints were fully completed on time, with most sprints having work from the subsequent sprint started. (Our sprints were 2 weeks.)

[[Feel free to delete the post if it does not fit your needs/style. Tell Al & Jim that I'm enjoying the radio podcasts, been through about 1/3 of them.]]

Free Email Updates!

Sign up for free email updates from
Net Objectives Thoughts Blog

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean-Agile, Kanban, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
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, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, 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