User stories that should be simple are frequently quite complex, written ambiguously, or have underlying needs that are hidden below the surface. Some should be broken up in to multiple stories. You may not know how best to write a user story and communicate needs. Many developers are not trained in the techniques needed to break through in this challenging environment and quickly get a clearer understanding of user needs.
Break Through Thinking
Make this break through: it’s not the designs you bring, or the solutions you suggest, that will clarify needs – it’s the questions you ask that determine how quickly a solution can be implemented. Good questions showcase your understanding and build trust between you and the user. Here are a few situations where a few great questions will help you deal with difficult user stories and difficult times:
Determining the success criteria
Here is a simple approach to clarifying user stories: attach your clarifications as acceptance criteria or test conditions. The user story could be all about the user interface. The success condition in the mind of the user could be very different “A user can buy our product.” By focusing on the outcome not only is the capability needed clearer, but you also now have a clear understanding of what to focus on with users during sessions.
Understand the context of the described User Story
Often user stories lack business context and sequence. You need to know where something fits and should not be shy about clarifying these facts. Your stakeholders and subject experts are the only ones that know this information. Try this sequence of questions:
- I understand this story fits into the purchasing area, tell me, what initiates a transaction?
- What do you want as the successful outcome of the transaction?
- Can you give me a quick outline of the steps that happen in completing this transaction?
- Where does this story fit into that sequence?
Get at the details of a transaction!
When dealing with transactional systems, it is critical not to make assumptions about how these transactions work. There are invariably interdependencies that need to be found and hidden variations and conditions that need to be uncovered before a successful outcome can be achieved. Again – don’t assume your stakeholders can proactively tell you the answers. Assume instead that your questions can guide stakeholders to giving you the critical information needed.
Let’s assume, for example, that the story is about validating a customer’s identity in a call center application. For any transactional processing application, use this sequence of questions to flesh out the details:
- What information do you need to know to validate the customer?
- What do you do with that information?
- What typically happens once you’ve validated a customer?
- Is there anyone that needs to provide you with some of this information you need to validate a customer?
- Is there anyone that needs to know that this customer has been validated?
You are listening for two things – a clear understanding of the process and business rules for a particular piece of functionality. You are also listening for the words “that depends”. At which point you ask, “on what does that depends?” ‘That depends’ always means a variation or condition and you’ll need to probe after you’ve talked about the core five questions above on these variations, how they impact the process, and if there are other variations or conditions that exist that might change the process.
- What other things / outcomes could occur other than the typical outcome?