Storycrafting: From Idea to Action in the Face of Unknowns

be either just English or user-configurable to one of eight languages.” That difference would greatly affect the size of the story. So, pick one and state the story unambiguously. There is no “mystery meat” in a proper agile story!

It’s OK if you want to ask the team to give an estimate for two different versions of the story. Write the two stories, but make each one unambiguous.

To tell whether you’re done writing the story, ask whether it is clear enough for the team to estimate how much work it entails. The “No Mystery Meat” rule is important, because we need to prevent backsliding. Chip and Dan Heath address it this way in Switch:

If you’re worried about the possibility of rationalization at home or at work, you need to squeeze out the ambiguity from your goal. You need a black-and-white (B&W) goal. A B&W goal is an all-or-nothing goal, and it’s useful in times when you worry about backsliding. Maybe your B&W goal for your alcohol consumption could be “No wine ever.” No wiggle room there. And what if we changed our New Year’s resolution from “Be healthier” to “Gym every day” or even “No more Cheetos”? Those goals leave nowhere to hide. Either you’ve got damning orange Cheeto dust on your fingers or you don’t.” [1]

Stories Evolve
This patient signature story evolved further. During discussion of the acceptance criteria later on, the team and stakeholders decided to drop these items from the conditions of satisfaction:

• Diagnosis code is captured.
• Each user data entry is validated.

That decision was made some days after the storycrafting session, when they met to estimate stories. It became clear that having the story completed sooner was more important than having these two elements.

“What?” you might say. “Skip data entry validation? That’s not high-quality code.”

It’s OK to put the data entry validation work into a later story, so long as the team and stakeholders recognize that fact. How? By not deploying the software until that feature is implemented or by taking extra steps to compensate for the missing data validation feature. Another option is to code this story without data entry validation, unit test it, and then disable the whole story until the postponed parts are implemented.

These are all valid paths to consider. This is what it means to assemble the stories together to form a pathway to customer value.

We’ve now followed the example of transforming a fuzzy agile story into a crisp, useful story that has strong safeguards against backsliding (no mystery meat!). We’ve seen how a pattern of questions tested the need for the story (who benefits?), determined the benefit, and established ahead of time what will be acceptable proof of the new capability. The questions provide vision for one strand of the work to be done.

The next parts of this article will address these questions:

• How do I know whether I’ve got the stories small enough?
• What if a story is bigger than a whole iteration and shrinking it would remove its customer value?
• How can stories help a feature that hasn’t been done before and has no basis for estimation?
• How do we use stories across specialized teams—software, electronic, mechanical, etc.?

References

• Heath, Chip and Dan Heath, Switch (Crown Business, 2010), 86-87.