The rest of the post tries to explain a set of guidelines that we use to avoid incurring in these two problems.

Actionable Requirements

At the beginning of this post, we talked about “requirements” as if we all know what they are. However, everyone thinks about requirements in a different way, and the word is overloaded with meaning.

For this reason, let’s make sure we are on the same page here: for us, a requirement is what is given as input to the design & development phases to create the product.

Not very specific, I know. Anything can be a requirement: a request made informally at lunch, a lengthy document with all possible implementation details, also a customer complaint.

Our objective is to write requirements that are good for how we work, and we call them actionable requirements.

A requirement is actionable by our design & development team when they can take it, and build the best possible product for the end customer. This means that the requirement must contain all the necessary information and context to allow the people who take it to do great design & development.

What are, then, the characteristics of a good requirement?

First, it must generate a shared understanding across the team and the customer; inconsistent interpretations would lead to disappointment.

Second, it must allow design freedom by giving context as to who the feature is for, and what they are trying to accomplish; if too prescriptive, it will constrain design and deliver a suboptimal result.

Third, it must be based on real wants and wishes of users, and not on speculation; would you buy shoes as a present without asking what foot size they wear? I guess not.

In the next few sections, you will learn which techniques we use to create actionable requirements.

The Requirements Gathering Conversation

In every one of the formats that we’ll list below, there is one key thing you will be doing: talk.

The “Requirements gathering” is an active process, we don’t wait for documents, we talk with customers and extract requirements. For this reason, the most important skill is the ability to moderate a discussion and ask the right questions.

In this section, we will understand the concept of “stories” and why they are the key to successful requirements gathering conversations. We will then go through a few techniques to have a successful conversation. This process requires skills and expertise, and it’s something you will have to practice a lot and make your own mistakes to learn.

Stories

You probably already know about User Stories. Well, forget what you know. Let’s start at the beginning.

Kent Beck suggested the concept of stories in “Extreme Programming Explained”. No, they were not invented by Scrum! They were not even part of Scrum at the beginning.

And, incredibly, they had nothing to do with “As a … I want to … so that …”. That came much later as a way to triage ideas (stakeholders not able to write their ideas in that format could not submit backlog items).

So, what are stories? When you have a final product, you can tell a story about you using it. For example, you can easily describe the google search interaction:

As the user types, suggestions relevant to what he’s typing appear, and they can jump to what they need even before they have spelled it out completely. If the user makes a mistake, the suggestions are still relevant, as they can guess it was a mistake. The interaction is fast, faster than typing, even fast typers will love the advantage provided by instant search.

The idea of stories is to tell this before the feature is implemented, instead of trying to formulate it as detailed requirements, such as:

there shall be a text input box

there shall be a list of possible search matches

the list of matches shall update based on what is currently in the text input

the list of matches shall be updated within 250ms, on average, after the text input changes

While this describes the product accurately, it does not provide context, it does not give meaning to the interaction, and it will create lost in translation.

For example, the 250ms is an arbitrary number defined in the design phase, and it might be insufficient for the real goal “faster than the fastest typing”. Or it might be moved to 400ms due to complexity, thus rendering useless the instant search interaction.

On the contrary, the story above describes the outcome for the user, their expectations, their needs. It will be resilient to misinterpretation from designers and developers.

But remember, documents don’t work! So even a story like that cannot transfer the full message without a conversation attached to it. For this reason, Kent Beck suggested that stories should be given a title and a short description, then the people who need to interact with the story get together and talk about it. You cannot write a story and have someone else read it, and expect this is enough. Not between the customer and the product manager, nor with designers and developers.

This is why we call them stories: because we tell them, we narrate. Not because they say “As a user …”.

A good story:

has a title and a little bit of description that help recall the conversation is always discussed among the people that need to interact with it describes not only what to do, but the full experience of the user

Who, Why, What.

To help you structure your conversation using stories, remember that you always have to answer these three basic questions, in order of importance:

for whom is this feature? → the user why do they need it? → the pain point what is it? → the capability

Try to focus as much as possible about the user, and their pain points. There can be many capabilities that solve those pain points for the user, and they can always be defined as we go. But if we forget for whom we are building, and what their needs and wants are, we won’t be able to design.

The five whys: figuring out the root need

When an airplane crashes, the engineers try to understand why and fix the problem. For example:

→ question: “why didn’t the plane go left?”

→ answer: “a flap did not move.”

However, they don’t stop there: why didn’t it move? Because the engine had low power. Why? Because it was too cold. But why was it too cold? Because it was placed outside the insulated area. Why? Because it was already full inside.

So you could either get a stronger engine or change its location and ensure this doesn’t happen again.

This is called root cause analysis → don’t stop at the symptoms, try to find the root cause and solve it. The “five whys” rule comes from Toyota.

What we do is very similar, and we can call it a root need analysis → don’t stop at the first need, ask why, and find the root need of the user:

I want to have a reminder feature → why? because I forget about tasks in the software → why? because I don’t have time to check all my tasks every day → why? because it takes too long → why? because they are spread everywhere in the app

Maybe the solution is not a complex reminder system with notifications. Maybe we can solve 80% of the need by simply listing all the tasks in a task summary page.

Understanding the root need is probably the most important job you have during requirements gathering conversations.

Your job is to simplify: real-time design

As we said before, “there is always too much to build”. Our objective is to build the least amount possible while providing the maximum value. We say, optimize value over scope.

A good way to do this is to stress the requirement. As in the previous example about reminders, your job is to find the root need and suggest, as you go, alternative implementations (capabilities) that would address the need. You are not doing a final design here. You are doing a real-time design with the objective of finding the smallest possible scope that keeps the story intact.

To do this, it’s good to use a whiteboard, and sketch things in real time, then start changing and removing them, making them more and more minimal.

Remember: your objective is to get a perfect view of the root need, not to have the perfect design. Don’t waste your time with design details that don’t help you focus on the need.

Did you remove what was not needed?

A word about estimation

When we quote projects in a fixed-price fashion, we need to estimate the work we will perform. This phase becomes extremely relevant in that scenario, as it can also work as a preliminary design session that helps the team estimate the effort. In this case, try to think about potential complexity areas in the design, and address them, even if they don’t give you much about the need. It’s useful to do this collaboratively with someone else in the team, engineers, and designers, as this phase is critical for good project estimation.

stories versus tasks

Stories are a way to start, and recall, conversations. They give context, the “big picture”. Stories don’t tell you what to implement in details. When designing and developing, your job is to split stories into smaller and smaller chunks.

If a smaller chunk is a simple description of something to implement, and it’s absorbed in the overall story conversation, we call it a task. Don’t force a story template on everything: use stories for what they are useful, not because you are told to do so. Use your common sense.

Formats

We will list here three formats that can be useful to structure requirements gathering conversations. They all overlap in what they do, and it’s up to you to find the right one for the situation or work with a mixture of them. We plan to illustrate how we apply each of them in further posts.

Event Storming: a particularly useful approach to understand the context in which the product lives, its actors (users) and the pain points they suffer. It’s a good way to start the conversation in complex ecosystems, but it’s not indicated to begin designing and working on simplification. User story Mapping: the right format to nail the root need and start designing. It gives you a simple way to map the feature and its capabilities while allowing you to keep the high-level view of the actors and needs. Also, it’s perfect for scoping out capabilities (simplification and prioritization). User interview: perfect to validate the hypothesis you make about pain points, and discover new user needs and wants. You can use it right after your first conversation, or at the end of the customer conversations, to validate the output. Or whenever you feel it’s appropriate: it will always help you in ensuring you are on the right track, and not missing important things.

Conclusion

This was a brief introduction to what we think is the most effective way to perform requirements gathering: let us know if you have feedback and suggestions on how to improve. We plan to write more posts about this topic, where we dive into the details of the approaches that we introduced.