(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Wednesday, December 06, 2006
Repost: How to Manage an Iteration with a Cork Board and a Stack of Three by Five Cards
On a recent project, we had very good results managing the work within iterations with a giant cork board. The board was divided into columns.
To begin, stories were written by a program manager. He owned the absolute right to define “done-ness” for a story. The stories were written on three by five cards and placed in the first column, “story”.
Programmers were assigned to work with the program manager to size stories. They would usually, but not always, end up working on the code. But first, they negotiated acceptance tests with the program manager. Both sides had a veto on the test suite (an acceptance test is not exactly the same thing as a unit test: see How to Use Acceptance Tests to Ship Software).
When they agreed on a set of tests, the tests were documented (preferably on the card) and the card moved to the next column, “accept-able”.
The programmers were blocked from coding or estimating until this point. Very important! Now they negotiated estimates. When an estimate was done, the card advanced to “sized”. But no programming started.
Based on estimates for most or all of the stories, the stories were prioritized and some could be dropped or delayed. The stories that would be in the iteration stayed in “sized” but now would have names attached to them. By convention, we placed the assigned stories in the lower half of the board.
Now a date was set for the entire iteration and coding would begin.
When a story was ready for testing, it advanced to the next column, “test-able”. The program manager would validate the story, and it would advance again to “accepted”.
If it didn’t validate (boo) it bounced back to “sized”: we had no column for “work-in-progress” (the assumption was that if a story was sized and assigned to someone, they were thinking and/or coding).
When all the stories were “accepted,” we’d do a big acceptance test again, catching any regressions. Some of the stories would bounce to a “penalty box” in the lower right hand corner of the board. We felt it was important to highlight the shame of something being “accepted” but breaking.
The iteration was done when all of the stories were simultaneously “accepted.”
So the columns were:
The Benefits
This process was really light weight. That made it possible for us to have more iterations within the project; we worked on one and two week iterations.
The visibility of the cork board was invaluable: everyone knew where we were, every day. This created a sense of urgency right from the start of each iteration: “we have to get all this done for next Friday? let’s get those acceptance tests defined right now!”.
The process was rigid where we needed it to be rigid (acceptance tests before estimates), but flexible where we needed to be flexible (negotiating acceptance tests, locking down the set of stories after estimates)
Putting the entire team into binary, project-wide iterations really lowered our integration grief.
The Fine Print
Other methods were used for choosing themes for iterations and managing the project as a whole. This is just how we worked within an iteration. In fact, by strict definition the cork board didn’t manage the iteration so much as help us understand where we were and help us follow a set process for movement: I call this Administration rather than Management.
“Now a date was set for the entire iteration and coding would begin.”: That’s a lot of hand waving! Deciding what to include and what to drop is a really complex weaving a deep understanding of the project risk factors, a desire to show constant visible progress (“Demo or Die”), negotiation with stakeholders, negotiation with the developers… A very hard problem.
(Many thanks to Eric Torreborre, whose post Writing on the Walls reminded me how important the physical manifestation of a project is to getting the project done.)
On a recent project, we had very good results managing the work within iterations with a giant cork board. The board was divided into columns.
To begin, stories were written by a program manager. He owned the absolute right to define “done-ness” for a story. The stories were written on three by five cards and placed in the first column, “story”.
Programmers were assigned to work with the program manager to size stories. They would usually, but not always, end up working on the code. But first, they negotiated acceptance tests with the program manager. Both sides had a veto on the test suite (an acceptance test is not exactly the same thing as a unit test: see How to Use Acceptance Tests to Ship Software).
When they agreed on a set of tests, the tests were documented (preferably on the card) and the card moved to the next column, “accept-able”.
The programmers were blocked from coding or estimating until this point. Very important! Now they negotiated estimates. When an estimate was done, the card advanced to “sized”. But no programming started.
Based on estimates for most or all of the stories, the stories were prioritized and some could be dropped or delayed. The stories that would be in the iteration stayed in “sized” but now would have names attached to them. By convention, we placed the assigned stories in the lower half of the board.
Now a date was set for the entire iteration and coding would begin.
When a story was ready for testing, it advanced to the next column, “test-able”. The program manager would validate the story, and it would advance again to “accepted”.
If it didn’t validate (boo) it bounced back to “sized”: we had no column for “work-in-progress” (the assumption was that if a story was sized and assigned to someone, they were thinking and/or coding).
When all the stories were “accepted,” we’d do a big acceptance test again, catching any regressions. Some of the stories would bounce to a “penalty box” in the lower right hand corner of the board. We felt it was important to highlight the shame of something being “accepted” but breaking.
The iteration was done when all of the stories were simultaneously “accepted.”
So the columns were:
- Story
- Accept-able
- Sized:
- (upper) Not Assigned
- (lower) Assigned
- Test-able
- Acceptance:
- (upper) Accepted
- (lower) Penalty Box
The Benefits
This process was really light weight. That made it possible for us to have more iterations within the project; we worked on one and two week iterations.
The visibility of the cork board was invaluable: everyone knew where we were, every day. This created a sense of urgency right from the start of each iteration: “we have to get all this done for next Friday? let’s get those acceptance tests defined right now!”.
The process was rigid where we needed it to be rigid (acceptance tests before estimates), but flexible where we needed to be flexible (negotiating acceptance tests, locking down the set of stories after estimates)
Putting the entire team into binary, project-wide iterations really lowered our integration grief.
The Fine Print
Other methods were used for choosing themes for iterations and managing the project as a whole. This is just how we worked within an iteration. In fact, by strict definition the cork board didn’t manage the iteration so much as help us understand where we were and help us follow a set process for movement: I call this Administration rather than Management.
“Now a date was set for the entire iteration and coding would begin.”: That’s a lot of hand waving! Deciding what to include and what to drop is a really complex weaving a deep understanding of the project risk factors, a desire to show constant visible progress (“Demo or Die”), negotiation with stakeholders, negotiation with the developers… A very hard problem.
(Many thanks to Eric Torreborre, whose post Writing on the Walls reminded me how important the physical manifestation of a project is to getting the project done.)
Labels: agile
Comments on “Repost: How to Manage an Iteration with a Cork Board and a Stack of Three by Five Cards”:
<< Home
This process sounds like it works very well, but what happens when it comes time for acceptance of a story and the customer realizes they need to change requirements?
How does that affect delivery of an iteration if you now have to go back and make changes to a story, starting from the beginning?
How does that affect delivery of an iteration if you now have to go back and make changes to a story, starting from the beginning?
Ben:
That's actually a common case. Humans don't know what they want until they see what they thought they wanted and realize that they were wrong!
The answer is... that's what the next iteration is for. In fact, that's one of the main drivers for iterative development. The 'sunk cost' of writing the wrong stuff is lowered, and the opportunity to fine tune requirements based on experimenting with working, finished code is increased.
That's actually a common case. Humans don't know what they want until they see what they thought they wanted and realize that they were wrong!
The answer is... that's what the next iteration is for. In fact, that's one of the main drivers for iterative development. The 'sunk cost' of writing the wrong stuff is lowered, and the opportunity to fine tune requirements based on experimenting with working, finished code is increased.
<< Home
