AGILE IN ACTION

Saturday, 4 February 2006

Making the quality-factor visible

To deliver working increments of software, it’s not enough to show all the tests passing. You also want to know that each user story has a production-quality implementation. This is why knowing when you’re done on a user story includes a mental check of the design and all the code.

Some teams at Thoughtworks use a single information radiator to convey both the functional completeness of a user story and its implementation quality. Using both dimensions of a whiteboard, the x-axis represents the functional completeness and the y-axis represents the implementation quality. The story cards being developed in an iteration are placed on the whiteboard. A card is moved to the right as it becomes more functionally complete, and moved upwards as its implementation quality improves.

I plan to reconfigure the Current Iteration area of my planning board to be like this.

Reference: Alistair Cockburn on Communicating, Cooperating Teams .

Creative Commons Licence

Recent Posts

  1. Managing costs provides a false sense of security
  2. State of Agile survey for 2011 tells a familiar story
  3. (I can't get no) satisfaction, let alone customer delight
  4. Positive emotions and purpose
  5. People don't buy what you do, they buy why you do it
  6. Too busy chopping wood to sharpen the axe
  7. So you want a fresh apple
  8. Systems are seductive
  9. Crack cocaine problem-solving and complexity
  10. Beware the Coefficient of Fiction

Archives

  1. 2012 (4)
  2. 2011 (24)
  3. 2010 (31)
  4. 2009 (41)
  5. 2008 (69)
  6. 2007 (152)
  7. 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)
      1. Don't be afraid to make mistakes
      2. APLN and collaborative leadership
      3. Scrum ba
      4. Ten-minute build, continuous integration and developer rhythm
      5. User stories part 3: Using spikes to help estimate user stories
      6. User stories part 2: Adaptive planning
      7. User stories part 1: What is a user story and who writes them?
      8. Ba
      9. Watch out for the mini-series
      10. Ideal time vs. story points
      11. Making the quality-factor visible
      12. User stories and tasks
      13. Knowing when you're done
      14. Switching pair-programming partners
    12. January (24)
  8. 2005 (63)
  9. 2004 (2)

Tags

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