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.