Schedule and Events



March 26-29, 2012, Software Test Professionals Conference, New Orleans
July, 14-15, 2012 - Test Coach Camp, San Jose, California
July, 16-18, 2012 - Conference for the Association for Software Testing (CAST 2012), San Jose, California
August 2012+ - At Liberty; available. Contact me by email: Matt.Heusser@gmail.com

Friday, January 12, 2007

Agile Metrics - II

I've been having an off-line discussion with Jared Quinert that follows-up my post on Agile Metrics. Specifically, he noticed that I refer to the state a project is in to indicate that a project progresses in a way that is non-linear. For example: If the customers reject a build badly enough, it could bounce back to development, or even "needs requirements", which indicates that we built the wrong thing, completely missing the mark and not realizing it.

Jared saw my throughput metrics and had some comments; I thought they were worth sharing. (These are his words, used with permission)

You might have a bunch of different states your story could be in:

Needs       In Dev       Cust.
Req's                            Test
[ ]               [ ]                 [ ]

We can think of these as indicating a story's current state, and that maybe all three of these things are true of a story simultaneously. I noticed a tendency for people to look at the boxes arranged left-to-right and read:

Needs       In Dev       Cust.
Req's                             Test
[ ]--------->[ ]--------->[ ]

So instead of collaborating to work toward a completed story, it became waterfallish, with small analysis-code-test phases. Your spreadsheet reminded me that the wording can be important. Ours was worded more like -

Story                 Design             Dev             Tester
Complete      Reviewed      Complete      Verified
[ ]------------------>[ ]----------->[ ]---------->[ ]

...which prompted even more waterfallish behaviour, because the wording describes activity completion (or trigger events for a state transition). Even on a later project, the story cards were arranged in columns and pushed across the wall from left to right. I don't think this is a great model for what we're usually trying to achieve.

You've pointed me at some ideas for different visual representations that might get people away from their old mental models. I know that ultimately most of it comes down to values, but it's nice to know if there are 'tricks' which can help guide the team's thinking.

1 comment:

TexicanJoe said...

I just posted and entry that relates to this subject. You can find the post here Requirements -> Stories.

I would welcome any comments you might have.