As a user, I can add social security number, so patient logs have social security numbers
As a developer, how would you react if you were given this user story? Would you throw it back in the face of the product owner, or would you try and understand it?
How about the following dialogue?
- Developer: “What are we hoping to achieve with this story?”
- Customer: “We hope that the patient logs will have social security numbers. Duh.”
- Developer: “Sorry, I was unclear: What problem do you experience now that we don’t have the social security number?”
- Customer: “Oh! We need the social security number when we bill the customer.”
- Developer: “I see. So what happens now?”
- Customer: “Well, since the patient has left the hospital, the billing department has to phone or send postal mail to get the information. That’s a lot of work.”
- Developer: “What places in the application can we add this information?”
- Customer: “We’ll add it to the patient journal.”
- Developer: “Who updates the patient journal, and when?”
- Customer: “Whops. The doctor updated the journal after the patient has left. We better add it when secretary checks the patient out. So that would be in the appointment system”
- Developer: “What other places could we enter this information?”
- Customer: “Well, we could have a field for the social security number when the patient first requests the appointment”
- Developer: “So, we have considered two options: The appointment system at checkout or the appointment system when the appointment is booked. What other ways could we get the same information?”
- Customer: “We could collect it from the governmental web service, I suppose.”
- Developer: “What would you like us to try first?”
- Customer: “Since the patient normally fills in the appointment request themselves, let’s try that out first.”
- Developer: “Let’s see if I get you correctly….”
In order to have the required information to send an invoice, as the billing department, I want the patient to enter their social security number when they request an appointment
What you’ve just witnessed is a series of questions that can be organized like this:
- Goal: What are we hoping to achieve? How will the user story change the world?
- Reality: How are things working now?
- Options: What else could we do instead? In addition?
- Will: What will we do? What is our plan of action
The GROW mnemonic is a tool from professional coaching. That is: Talking to people about the problems and ambitions in their professional and private lives. It helps guide a novice coach through a coaching conversation and focus on the problems of the person being coached. Or, in this case: On the business value we want to achieve.
At the end of the day, as a developer you will be judged not on whether you followed the orders you were given, but whether you understood and delivered what was really needed. By asking your users, your product owner or your domain expert what they really, really want (Goal), it will be easier for you achieve. And if you don’t have access to the relevant people, these questions can still help you guide your thinking about the requirements.
You can read more about the GROW model at What-is-coaching.com and many other websites devoted to helping people get to the best of their ability.
A big thank you goes to Antti Kirjavainen for suggesting the patient journal example and for coaching me in the process of writing this article.
References: How to GROW a user story from our NCG partner Johannes Brodwall at the Thinking Inside a Bigger Box blog.
