Saturday, January 28, 2006

Root cause analysis using 5 Whys

Posted by Simon Baker

My brother is a SixSigma consultant and my nephew is at that age where he asks "Why?" a lot. I’m wondering whether he’s been trained by his father to use SixSigma ‘s root cause analysis technique, the 5 Why’s?

The technique is simple. Write a description of the failure on a whiteboard. This helps formalise the failure and also helps the team involved to focus. Ask the team, 5 times, why the failure occurred, each time writing the answer given on the whiteboard. Repeatedly asking the question helps to burrow through the symptoms and identify a root cause of a problem (there may be more than one root cause). 5 is a rule of thumb. You may ask the question fewer or more times than 5 before you find the root cause of the failure.

5 Why’s applied in a real retrospective

In a previous post, I talked about the experiences a development team were having in relation to slop and slack . One particular problem was that planned user stories were being descoped from each iteration as the last day approached. Here’s the analysis:

Failure : Consistently fail to deliver all the user stories to the Product Owner, that are planned during the iteration planning meeting.

  1. Why are user stories being descoped towards the end of each iteration and not being delivered to the Product Owner? Because we run out of time.
  2. Why do you run out of time? Because most of the user stories take longer than we estimated.
  3. Why do most of the user stories take longer than your estimates? Because most of our estimates are bad.
  4. Why are most of your estimates bad? Because we don’t fully understand enough of the details of a user story when we estimate. And although we triangulate to completed user stories, the task effort recorded for those completed stories differs significantly even though they have the same story points. (The tracking data showed that user stories with 5 story points had tasks with a total recorded effort between 2 and 4 ideal days). [2 problems identified here]
  5. Why don’t you fully understand enough of the details of a user story? Because we’re not collaborating effectively with the customer during iteration planning.
  6. Why aren’t you collaborating effectively with the customer during iteration planning? Because most of the story cards are a mess of notes, so we get the customer to read them to us. [Root cause identified]
  7. Why is the tolerance on recorded effort so wide for user stories with the same story point value? Because we’re not revising the story point estimates.
  8. Why aren’t you revising story point estimates? Because we focus on tracking the tasks in ideal days. [Another root cause identified]

To address the 2 root causes, the following fixes were applied in the next iteration:
  • Encourage collaboration by using just a story name on the card (a technique suggested to Brian Marick by Rachel Davies ). The customer rewrote the remaining story cards.
  • At the end of the iteration planning meeting, each team member verbally state their commitment to deliver the planned user stories to the product owner and the other team members. This made the developers spend sufficient time with the customer, beforehand, discussing the details of the user stories to ensure they understood what was required before providing estimates.
  • Start using ideal pair hours to estimate user stories and record velocity rather than story points. It seemed nobody really liked story points. Since there was some confusion about what they really were or meant, the developers were never entirely confident about their estimates. The customer was happy to see time come back, although the concept of ideal time had to be explained.
  • Stop tracking tasks and start tracking running tests features .
  • As part of the collaboration between the customer and the developers, split the user stories being planned for the iteration so that they would take between 1and 2 days to complete. Smaller units of work are easier to estimate.

It’s been a while since these fixes were applied. They made a difference almost immediately with fewer user stories being descoped from iterations. Collaboration is increasingly more effective. There’s still room to improve the estimates, but the developers’ confidence has increased and now it’s a case of practice, practice, practice.

FIT has been used but only to produce automated acceptance tests. The next step will be to start using FIT to actually facilitate the collaboration with the customer. The aim is to produce the FIT documents before development starts on the user stories.

1 Comment

I stumbled upon, cant remember how, its been on my desktop for few days reminding me that it needs to be read.

I recently encountered a similar problem, i opted for using commitement driven planning as oppose to velocity and also encouraged tasks broken by the day during iteration planning. Not uncommon practices but the team didnt do this before.

The release plan still uses story points; devs have always been relunctant to provide estimates, story points seem to be an acceptable alternative at this high level.

Wonder if doing some basic story breakdown into tasks per day would have helped in your scenario? It seems to encoruage more thought, previously i found some devs eager to brush of a story into one big chunk of work just so they could get back to their keyboards.

We shall see how this new process will pan out.

PS. Great article

Comment by SpaceCowboy

Creative Commons Licence

Recent Posts

  1. Spark The Change - Innovation Governance
  2. Lean Day London 2014
  3. The Mechanics Of Meaning
  4. Engineering Design
  5. Debugging Grails Database Performance
  6. Grails for Hipsters
  7. Governance - Friend or Foe?
  8. The Energized Work lab is moving aboard ship
  9. Gus Power on the future of software development at The CW500 Club
  10. Agile On The Beach: Session: How Are We Doing?


  1. 2014 (4)
  2. 2013 (2)
  3. 2012 (27)
  4. 2011 (24)
  5. 2010 (31)
  6. 2009 (41)
  7. 2008 (69)
  8. 2007 (152)
  9. 2006 (128)
    1. December (16)
    2. November (26)
    3. October (7)
    4. September (11)
    5. August (7)
    6. July (7)
    7. June (4)
    8. May (4)
    9. April (4)
    10. March (4)
    11. February (14)
    12. January (24)
      1. Look after your product backlog
      2. 1-week iterations
      3. Root cause analysis using 5 Whys
      4. Agile In Action is now available at Artima
      5. Planning with the Horizon of Predictability
      6. The knowledge worker and the new organisation
      7. Setting Norms to help internalise Agile values
      8. Agile is ... Agile isn't ...
      9. It doesn't have to be about business value
      10. Task-switching is waste
      11. Flow, ideal time and the E-factor
      12. A Scrum Master is like a music conductor
      13. Slack != Waste
      14. Go on. You know you want to. Say 'Hello'
      15. Spike
      16. Why agile principles are important
      17. Pareto Principle
      18. My interaction style
      19. An 'aeroplane in flight' metaphor for agile tracking
      20. A Scrum Master is like a skilled helmsman
      21. Fun and games
      22. Innovation games from enthiosys
      23. Thomas Edison on 'Lean'
      24. The speed of thinking
  10. 2005 (63)
  11. 2004 (2)


agile (43) big visible chart (15) conference (43) culture (18) extreme programming (22) leadership (18) lean (47) people (27) planning (17) retrospective (18) scrum (41) story (19) team (30) testing (19) xpday (19)