Storycrafting: From Idea to Action in the Face of Unknowns

unknowns . I used a pattern of questions to prompt the project community—technical team, internal and external stakeholders, and domain experts—to supply the elements of good agile stories. Such elements include why this feature is needed by the user and how its performance can be demonstrated. In this case, “good” means that the stories can be assembled into a topology showing a few of the most promising paths for delivering customer value. Further, they are clear enough (no wiggle room) that the team members feel confident enough to perform them.

Let’s look at an example of how storycrafting techniques can sharpen the story in figure 1. A medical product company’s agile team has this story in its plan for the next iteration: “Need to get electronic patient signatures.” We’ll follow along as an agile coach (or ScrumMaster) asks a series of questions to make this a more useful story.

Question 1: If we never implement this story, who would miss it the most?
The team’s analyst says, “The billing department needs the electronic patient signatures, and right now the nurse gets the info on paper. When our handheld units can let the patient sign on the screen, then the bar code from the dispensed products already will have the signature associated.”

The coach says, “Oh, so patient signature is not the only data being collected, then?”

“We need to capture the legal disclosures that the patient signed for and the items dispensed, so that they can later be reconciled with the Biomet Product Master,” says the analyst.

The product manager says, “And there are financial disclosures, too, that the patient signs for. It would be good to also capture the diagnosis code, as well.”

Things are getting tangled now. Patient signature is the tip of a potentially big iceberg. We’ll sort out the scope of this story, but the first job is to figure out who is the main beneficiary of the story. Right now, it’s not so clear whether that is the nurse or the billing department. In this instance, more dialogue will clarify that the billing department’s life won’t change very much after implementation of this feature, because they already receive all this data, except it’s partly in paper form. But, the nurse’s job will improve because this will be a big time saver.

Stories often have more than one customer or beneficiary. Find the customer who benefits most. Then, write the story for that customer, using her role in the story. Let’s see what that looks like, starting with a classic agile story format:

As a <role, beneficiary>, I want <capability> so that <benefit>.

We might begin to write:

As a nurse, I want to capture electronic patient signatures so that...

Wait! We haven’t fully addressed what benefit we are after, so the coach has another question.

Question 2: How does this story benefit the Nurse (beneficiary)?
Note that the answer to question 1, “Nurse,” becomes part of question 2. The team members have several answers to question 2, so the coach makes a list on the white board. It looks like this:

Benefits to Nurse

• She makes fewer errors in record keeping
• She can give all the data to the billing department in an electronic format
• She saves time
• She can group related data together

Now is the time for the coach to remind the team that the story is not meant to say everything that can be said about a feature. It is a brief summary of key information. (There will be a home for all the details that are needed for implementation.) So, the