In a business application project, it’s not uncommon for the delivery team to be given a set of requirements from their client (whether internal or external). In my experience those requirements come with the best intentions to fast track a solution and provide the necessary details. However, working with these requirements can be challenging; they are unclear, inconsistent and lack detail. The requirements often include the solution, and it is not always the right solution. It can be difficult to understand the full picture of what we are trying to achieve.
In this article I share a series of things you can do, to take the requirements you have been given and turn them into a complete set of actionable user stories, which everyone understands.
Don’t throw the unclear requirements out
As business application specialists, it's our role to build on the foundation of the requirements we have been given. We don’t want to throw these requirements out. Usually, a huge amount of time and effort has gone in to pull the requirements together and they can be a great starting point. However, we also need to enable everyone on the team to have a common understanding. We should acknowledge the effort and refine these initial requirements into a clear, actionable roadmap for success. The key is collaboration and improvement, not dismissal.
The end goal
Start by clarifying the project's objectives and goals. Set a north star and align everyone on the same outcome as you work with requirements. This can help, get clarity and agreement as you turn the requirements into something that everyone understands. Use the questions in our Solution Canvas to help define and quickly document what the business is trying to achieve.
Who are the end users?
Often requirements do not state who the requirement is for. For example, they might be written in the format of “the system shall ….”. One of the first things we need to do is find out who will be the end users of the solution.
Get real
Then, you need to see the problems and the needs of your end users in the real world yourself. Watch how they work for a day. You might find things that your client missed or left out of their requirements.
Create empathy maps, persona profiles or user journey maps from what you observed to understand the users and their needs better. You can find out how to build user journey maps here.
You also want to ask the client for some real-world scenarios, stories and data, as you will use these to test the requirements. Request these things early, as they may take time for your clients to prepare. Also, be clear and advise them on what kind of data, scenarios, and formats you need.
Write user stories
Once you know who the users are, re-write the requirements as user stories. This helps us shift to a user-centric and more consistent approach by:
· Identifying who we're building for.
· Clarifying their needs.
· Understanding the purpose.
Here's a refresher on the user story format:
As a [type of user], I want [an action, a job], so that [a benefit/value].
See the whole picture
User stories help us to capture the requirements in a consistent and clear way that is easy for people to understand and work with. But user stories alone are not enough to show the whole picture. How can we make sure that we cover all the user needs from start to finish in their work journeys? Draw swimlane business process diagrams and map the user stories on them, connecting them together. Then test the process by using the scenarios, stories and data from our customer. Do this in a workshop with your customer and you will soon find out if there are any gaps in the user stories or process. In my experience, more often than not, you will find gaps!
Refine requirements with acceptance criteria
You now have user stories but may have vague acceptance criteria and not enough detail to build the solution. A good way to clarify the acceptance criteria and the solution design is to draw wireframes and pictures of what the solution will do. When people visualise user stories (words) in their heads, they are most likely visualising something completely different to everyone else. Drawing wireframes and pictures ensures that everyone has the same visualisation to refer to and this assists with refining acceptance criteria. I like to put the wireframes and pictures above the business process diagrams and link them to the process and user stories. Use the story, scenarios and data provided by the client to test these stories, processes and wireframes.
Iterate
You won't clear up these requirements in a few workshops or meetings. You may need to go over them with your client many times, depending on how complex the solution is and how much the requirements are missing. You may need to iterate through the following steps multiple times:
1. Identify the objectives
2. Identify the end users
3. Observe the end users in the real world
4. Draft initial user stories and process maps
5. Add pictures to the process maps
6. Build and test prototypes
For each of these iterations, test them with the real-world stories, scenarios and data that your client has given you.
Conclusion
In this post I have shared what you can to do gain clarity over vague requirements. By re-writing and testing requirements in an agile and user-centred way, you can understand the real problems and needs of end users and stakeholders. You can also validate your ideas and assumptions with feedback and data from your users.
This will help you avoid wasting time and resources on solutions that are not valuable, usable, or feasible.
Getting clarity over vague requirements is an ongoing challenge that requires constant communication and collaboration. You can always find new ways to ask better questions, listen to your users, and co-create solutions with them. Start experimenting today!