Define Needs

What do our Users need to succeed with what they are trying to achieve?

How do we analyze and define what they are trying to achieve? How do we analyze and define what they need to succeed with what they are trying to achieve? How do we analyze their goals?

Traditionally we have had a document called Requirements Specification (or something else) that has documented the Requirements on the solution we are building. Most of the time the User needs and problems have mostly been implicit or a thin part of that document.

This approach has been very unsuccessful for most parts for software development. For information on why, see Agile Foundation.

In the agile community there are a number of approaches to become more successful in translating User needs into solutions that fit those needs. As described in Value to User we occasionally want to solve for other needs as well. The three most common reasons for an investment in a change are:

  • User needs
  • Our need to improve speed and/or quality in building solutions
  • Our need to reduce cost

Most refer to the agile approach of defining User Needs as Agile Requirements. I don’t think that sends the right message, when people hear the word requirement they tend to think of it as something that is “required” by someone. But an agile approach we are continuously and collaboratively trying to identify the most valuable need to solve for right now and exactly how to define that need. “Requirements” aren’t requirements in a traditional sense. We can change them if we like (most of the time) and can skip implementing them (most of the time).

But before we go into different approaches to understanding Users needs we need to thoroughly understand who the Users are. Users are described by Personas that helps us understand who they are and what their goals are.

Here are some popular agile tools that help us analyze and define needs:

  • Value Proposition Canvas
  • Impact Mapping
  • Customer Journey Mapping
  • Personas
  • User Story Mapping
  • Themes and Epics
  • User Stories
  • Use Cases
  • Other options

Value Proposition Canvas, Impact Mapping, Customer Journey Mapping and Personas are described in the Product Strategy section. If there are major changes in any of these tools, it is likely to be a change in the product strategy.

User Story Mapping, Themes and Epics are different ways to create a Roadmap so it is described in the Roadmap section. The Roadmap deals with higher level planning.

Please note that the tools described above helps us understand Users and their needs on a higher level.

That leaves us with User Stories, Use Cases and mock-ups as a way to define User Needs on a more detailed level.

User Stories

User Stories capture three things. Which User we are solving a need for, on a high level how we are solving the need and what goal we help the User achieve by solving this need.

This is the most commonly used format:

As a < type of user > I want < some goal > so that < some reason >

For example (for a Travel booking site):

As a traveller I want to reserve a hotel room

As a traveller I want to cancel a reservation

As an administrator I want to add a new hotel so that travellers can book rooms in it

Sometimes the “so that” part is left out when the reason is obvious.

As you can see this is an extremely lightweight approach to defining needs. Where are all the details, how will a developer know how to build a solution?

The main answer is through conversation in the team. Two other ways to include more details are by splitting User Stories or by describing details in the Acceptance Criteria.

The three C’s of a User Story:

Let’s take “As a traveller I want to cancel a reservation”. 

How far ahead can a reservation be cancelled? How will the cancellation be confirmed to the user, will they for example get an e-mail? And so on.

This can be detailed in conversation with the Product Owner who should have a solid understanding of the Users needs. The team can then together define the best solution just in time.

The detailed agreement can be treated in three different ways:

  • The team will remember it and don’t see a need to write it down
  • The User Story can be split
  • The details can be captured as Acceptance Criteria

All three are valid options and experience helps guide us to the best option in each situation.

If it for example is decided that the traveller that are premium members can cancel same day up to 12:00 without fee and that nor travellers can only cancel the day before without fee this could be captured as a split of User Stories or as Acceptance Criteria:

As a regular member I can cancel the day before without fee

As a  premium member I can cancel same day up to 12:00 without fee

In this example we actually also split the initial User into two different Users and we should think about and update Personas accordingly if they are impacted.

Or as Acceptance Critera:

  • Verify that premium members can cancel same day up to 12:00 without fee
  • Verify that premium members can cancel same day after 12:00 with 10 % fee
  • Verify that regular members can cancel the day before without fee
  • Verify that regular members can cancel same day with 10% fee

A common question is why don’t we just write down all this information down from the beginning? The thing is, that’s what we used to do when we were following the Waterfall approach. It has over the decades turned out to be an approach that is highly unsuccessful for software development.

When we agree on details just in time together with the team we gain the following benefits:

  • Better use of teams expertise – some solutions are easier to implement than others and some solutions will be much easier to use etc and the teams collective input is valuable
  • The team gains better understanding through the discussion than reading from a paper
  • Since we don’t decide details long in advance before we need them we can be more flexible in what we choose to do based on our learnings – some User Stories might not be implemented at all as we learn more about our users and our solution and some stories will be done in a completely different way based on what we learn

But there are also some traps related to this approach that you should be on the watch out for:

  • Product Owner is guessing what Users need and solutions frequently needs to be redone. Solve by spending more time with users before decisions are made.
  • Product Owner does not have adequate understanding of User needs when planning the work with the team. Solve by doing Product Backlog refinement before work is planned (or pulled).
  • Definition of Ready can help mitigating both of the above.

Use Cases

Use Cases are a more traditional approach to defining User Needs. Use Case tends to be more detailed in their textual description than User Stories.

I find Use Cases useful when it is too hard to keep track of all details in a particularly complex scenario and breaking it up in smaller User Stories would cause to much challenges with understanding of the full picture. If remembering details in a scenario and the details are known and stable it can make more sense to create a Use Case rather than a User Story.

The cancel reservation scenario might look something like this if it was described as a Use Case:

Use Case: Cancel room reservation

Actor: Traveller

Brief Description: This Use Case describes how Travellers can cancel a room reservation

Preconditions: The Traveller has one or several active reservations for rooms

Basic Flow of Events:

  1. The Use Case begins when a logged in Travellers selects to Cancel room reservation
  2. The application displays the different rooms that the Traveller have active reservations for
  3. The Traveller selects the reservation to be cancelled
  4. The application informs the customers about the terms for the cancellation
  5. The Traveller confirms cancellation
  6. The application cancels the reservation with the hotel
  7. The application sends a confirmation of cancellation to the Travellers registered e-mail

Alternative Flows:

The hotel can’t be reached

The application informs the Traveller that the hotel is currently not possible to reach and asks them to try again later.

Late cancellation incurs a fee 

For premium members this flow is activated when they cancel same day after 12:00

For regular members this flow is activated when they cancel the day before.

The application informs the Traveller that a late cancellation fee will be drawn from their registered card and draws 10 % in late cancellation fee.

Cancellation after check-in date

Traveller will be informed that Cancellation is not possible and will be advised to contact the hotel themselves.


Reservation has been cancelled and no further many will be drawn from Travellers account

Other Options


Sometimes neither User Story nor Use Case seems like a good fit. For example for bug fixes or more technical needs.

Most of the time I find that doing something along the intents of a User Story (with Card, Conversation, Confirmation) is the best approach.

But sometimes something completely different might be the best approach. For example a flow diagram or a decision table or something completely different. Keep an open mind and think about what the best fit is and don’t be too stuck in rigid conventions.

Non-functional requirements

Nonfunctional Requirements (NFRs) define system attributes such as security, reliability, performance, maintainability, scalability, and usability. As for other needs these are (for most part) not really requirements either. Some of them might be actual real requirements, for example security might be governed  by law. But even then, there are usually possible different interpretation so for most part it is best to treat Non-functional requirements in a similar way to functional requirement (or perceived needs). Explore and discuss. What is the real need? When is it needed? Why? Are we sure? Is it worth the cost?

One particular challenge with non-functional requirements is connected to software architecture. In an agile way of working we want to mainly solve for the current needs, not for needs we might have at some point in the future. But if we construct an architecture that will have to be completely redone in three months we might have made a big mistake. Finding the balance where main focus is on what we need now, without making too short sighted decisions that we will soon regret sometimes requires good thinking and discussions. Cost for the more future proof solution can sometimes break a small start-up so there is often no obvious path. And most of the time the truly agile approach is better – if it becomes a problem later on, it’s a happy problem, because it means we have succeeded in getting traction to our product and that likely means we can afford to build the better solution. Performance requirements for a successful product are changing all the time. If it is a risk you should make sure you continuously have a rolling forecast and make sure you don’t end up in a state where your application breaks – that can be a complete disaster.

Non-functional requirements (or rather needs) are usually quite hard to define. A product leader can almost certainly not define the him/herself without bringing in the technical expertise from the team. For example, the product lead forecasts that the coming three months we will have maximum 100 000 visitors per day. The team will then ask stuff like; which continents are they from, which parts of the system will they use, what data will they read/write, how long will they stay etc. To know where the strains will be put on the system you need to have very deep technical understanding. And the risky parts can continuously change as the system evolves. Long story short – you need to collaborate closely with the technical team to get this right and have solid discussions on what risks you can take versus the costs of less risky options. Sometimes you might even need to inform and discuss with upper management if it is a high risk or high cost scenario so the company leadership team can make an informed decision.

Scroll to Top