Storycrafting: From Idea to Action in the Face of Unknowns

coach asks them to come up with a short phrase that captures the primary benefit of this story. After a little more conversation, the story emerges:

As a nurse, I want to capture electronic patient signatures and related bar codes for better record keeping and billing.

There may be many benefits that the story can confer, but it’s important to focus on a small number of the most important ones or the ones that you need early. You can address the rest in later stories, so don’t worry about those yet.

Now, we’ve established the who, what, and why of this story. Are we done? No! The next question is crucial.

Question 3 (to the product owner): If the team came to you tomorrow saying, “The story is done. Will you sign-off?” what would prove to you that it is really completed?
The product manager and the business analyst start making a list on the white board. It gets longer and longer. It’s time for the coach to remind them that only a handful of key items is needed. Don’t try to write the full set of test cases or address the error paths here. Later stories can build upon this one, addressing edge cases and the needs of other roles.

On another white board, the product manager writes a small set of conditions that must be satisfied for him to sign-off the story:

Conditions of satisfaction:

• Legal and financial disclosures are displayed.
• Bar codes (patient ID, Items) and patient signature captured.
• Transaction is recorded.
• Diagnosis code is captured.
• Each user data entry is validated.

The most valuable thing about these items is that they are in the customer’s language. I find that people from product management or marketing are usually good at being concise. When you ask the question in this way, they seldom have trouble stating clearly and briefly what must be demonstrated.

Conditions of satisfaction tell us about the boundaries of the story—the constraints that are in force. They tell what must be demonstrated, how much must be demonstrated, and how accurate it should be.

In this project, the handheld units already exist and standard screen templates and data formats are in use. Testers and the product owner will work out further detail about the screen layouts, data formats, and so on during the iteration. In other words, there is confidence that the remaining details can be worked within the iteration where this story is implemented.

In another setting, there might be more uncertainty about those details of screen layout, navigation, interfaces to other systems, and so on. We’ll go deeper into the question of how to deal with unknowns later on.

Question 4: Are we done writing this story?
Stories evolve. They may start as just a phrase, like “Need to get electronic patient signatures,” but they need to be developed to a certain level before the team will be able to estimate them. (Some teams do not estimate stories. They simply queue them up and work them as needed, sizing them in retrospect, if at all. Whether the next step is story estimation or implementation, the point is the same: The story has to be fleshed out in preparation for it.)

We are done with writing this story when it is clear enough for the team to be able to estimate it. As mentioned, this does not mean every detail has to be spelled out. But, choices that affect the size of the work must be made. Suppose that in the patient signatures story, the product manager said to the team, “The screen text will