Feature Mapping – a lightweight requirements discovery practice for agile teams

Feature Mapping is a simple but effective way for teams to discover, explore and deeply understand the features their customers need.

In a Feature Mapping session, teams work through concrete examples of how a feature should work, breaking these examples down into steps and tangible business outcomes. Mapping out these examples helps team members discover edge cases, flush out assumptions, and spot uncertainty. This all contributes to building a better shared understanding of goals and business rules. And this helps the team deliver features sooner, with less waste, and with fewer defects.

Feature Mapping works well for many different domains. For a front-end application, team members might explore the different ways users will interact with the application to achieve their business goals. Or for back-end applications, they may look at how data should flow through a system, or what different types of inputs need to be catered for. The concrete examples they study help them better understand business rules and constraints. Examples also make it easier to think of counter examples or alternative flows, which in turn helps discover new rules. It is this structured, systematic approach that makes Feature Mapping an effective and compelling alternative to more freeform requirements discovery workshops.

Feature Maps are also easy to convert into high quality, highly readable acceptance criteria. This makes them ideal for teams learning BDD, or for teams discovering a new or complex domain.

When should you do Feature Mapping?

Feature Mapping works best when done early and often. In terms of the BDD lifecycle model we saw in the previous chapter, it belongs solidly in the Speculate and Illustrate phases. In mature BDD teams, Feature Mapping is a staple of requirements discovery workshops or "Three Amigos" sessions.

The exact timing may vary from team to team. Scrum teams generally do Feature Mapping shortly before a sprint starts. Feature Mapping is structured enough to be a very productive collaboration tool, but flexible enough for teams to allow discussions about many different types of requirements. As a bonus, the detailed understanding that emerges from a Feature Mapping workshop gives the team a solid basis for estimations or sizing, should they be the sort of team that likes to give estimations on stories.

We can also do Feature Mapping at a strategic level, for high level product increment or release planning. This helps get an understanding of the different user journeys that we need to deliver, and also helps us slice and prioritise our stories. We will learn about this approach in more detail later on in the book.

What happens during a Feature Mapping workshop?

The best way to get an overview of Feature Mapping is to see it in action. To do this, let’s follow a real-world Feature Mapping session at it plays out. Meet Rachel. Rachel is working in the Compliance department of a large bank. Compliance are the folks who make sure the bank doesn't do anything it shouldn't, like taking on a customer without checking their identification and proof of address, or opening an account for someone who is an associate of a well-known drug lord.

For example, when a new business customer wants to open an account, the bank needs to run some checks, both to verify new customer’s identity and background, and to make sure that they are not likely to be involved in any high risk activities. This is a fairly complex process, often involving the expertise of many people. Rachel and her team need to streamline and automate this process, and make it more reliable.

When a new customer is on-boarded, their application is first reviewed by a junior compliance analyst. For simple cases, the junior analyst can approve or reject the application themselves. But for trickier cases, a junior analyst may not have the experience or authority, and a senior analyst needs to make the final decision.

In the current system, the junior analyst can send an application to a senior analyst when they are unsure. However, this is left to the initiative of the analyst, and they do not always know when they should escalate an application. And applications are sometimes approved without the right level of approval, which represents a risk for the bank.

This is not a minor issue. A competing bank has been in the news recently, suspected of helping terrorists and drug cartels through their lax anti-money laundering policies. This is not the sort of publicity Rachel's organisation wants to receive.

Let's see how Rachel and her team use Feature Mapping to get a better understanding of the problem they need to solve.

Starting with a story

To help reduce risk to the bank, Rachel has already worked with business stakeholders to define a user story related to review escalation. In particular, she has been working with Pete, the product owner. Pete has been working in compliance for over a decade, and has in-depth knowledge about the domain. Together they have come up the the following user story:

They have also identified some key areas where the business would value automated escalation, and these have been noted down as high level acceptance criteria for this requirement:

• People with financial dealings with high or medium risk countries should be escalated
• People working in a high or medium risk industry should be escalated
• People without a local address should be escalated
• People opening an account with large amounts of cash should be escalated
• Blacklisted customers should be refused immediately

Rachel’s team run two-week sprints. On the Tuesday preceding the start of each new sprint, the team gathers to discuss what they should build next. On this particular Tuesday, Rachel wants to talk about Review Escalation. This is an important feature so Pete comes along too.

Review Escalation is a new topic for the team with some subtle business logic and a few new concepts. So far the team has only dealt with a very simple case, where an analyst can approve or reject the application with no prompting from the system. With this new requirement, the system will sometimes need to force an analyst to escalate an application. For these reasons, Rachel decides that Feature Mapping would be the most effective way to explore this new requirement.

The Anchoring Narrative

Rachel wants the team to start thinking about the story in concrete, tangible terms. So she kicks things off by walking the team through a real example of how the story will help.

“Joe is a junior analyst. He picks up a review for a new retail banking customer, Bill, from the list of pending reviews. Bill is a small business owner who runs an import business specialising in oriental furniture, decorations and Persian carpets imported from Iran. Iran is considered a high risk country, so Joe needs to escalate the application and let Sally the senior analyst make the decision. It is placed in the senior analyst todo list, and flagged as high priority.”

We call this story an anchoring narrative. She actually prepared this text with Pete before the meeting, printing out a copy for each team member to refer to during the workshop.

Notice how detailed and busy the story is? It is deliberately full of little details that make it feel real, and that grab the attention of the listener. This narrative isn’t about describing every possible path, or about listing business rules, exceptions or special cases. Rather, it is a starting point for the discussion. It gets people thinking and asking questions. For example, are small business owners treated differently to other types of clients? What other countries are high risk? What happens for medium risk countries? And so on. As the team explores the story, these questions help them look for variations, flush out assumptions and uncover uncertainty.

_You don’t need to make the anchoring narrative up on the spot. Many teams include the narrative text as part of the user story, alongside the initial acceptance criteria. Writing the narrative ahead of time results in higher quality stories. It also saves time for the other team members during the Feature Mapping workshop.

Mapping out an example

David is one of the developers on Rachel's team. He is pretty sure that he has understood Rachel's example, but he wants to be sure. He goes to the white board with some coloured post-its.

David: So the point of this example is to show how Joe handles a customer who has dealings with a risky foreign country?
Rachel: Yes, that’s right. Iran is a high risk country, so the application needs to be escalated.

David places a green post-it on the wall. In Feature Maps, green is the colour we use for examples. On the card, he writes a short phrase describing the example: "Joe escalates a customer with dealings with a high-risk country."

Concrete examples like this play a key role in Behaviour Driven Development. We use them to get a better picture of how a story should play out, and what sort of cases we should consider. They encourage discussion about other examples or counter-examples, which can help highlight areas that are unclear or misunderstood. They also form the basis of the automated acceptance tests that will, later on, verify that the feature works as intended.

In Feature Mapping, we explore examples in detail by breaking them down into steps or parts. Discussing what could happen at each step is a great way to better understand the example, and to find counter-examples or uncover uncertainty. This is what David does next.

David: So Bill owns an import business, and his company imports carpets from Iran. Since Iran is on our high-risk country list, we need Joe to escalate the review. The system prompts him to escalate the review, and he does.

As he speaks, he writes these steps down on three yellow post-its and places them to the right of the example card:

Ever the diligent developer, David is already imaging what changes he will need to make to the user interface. Franky, the other front-end developer, also chips in:

David: We can already get the list of high risk countries from our reference data. So we could just add checkboxes for each country, so the analyst just needs to ask the customer which countries they have dealings with, and tick the right boxes.
Franky: That would be a lot of checkboxes. I think a search box and a control where you can add and delete countries would be better; I know a Bootstrap component that would work perfectly. Updating the UI should be easy enough; I think we can have it done by the end of the week.

During requirements discovery workshops, it is easy, and very tempting, to dive straight into solution mode. But this often means designing a solution without fully understanding the problem we are solving. And once we start talking about a particular solution, it is easy to get bogged down into discussing the implementations of that solution, losing focus on the bigger picture.

In Feature Mapping, we use the idea of consequences to help us avoid this trap.

Identifying consequences

Tara, an experienced tester, is well aware of the problems that comes from designing technical solutions too early. She stands up and takes some more coloured post-its.

Tara: Hold on, not so fast. Before we dive into the screen designs, we need to be sure we understand what problem we are solving. What are the outcomes we expect? Where does the value for the business really come from in this case? What evidence will we see when this feature does what the customer needs it to do?
Rachel: There are two important things. The first is that reviews should appear in the senior analyst todo list, so that Sally the Supervisor can pick it up. But the real value is that this happens automatically, whenever we onboard a customer who has business dealings with a risky country.
Tara: Gotcha. But you also mentioned something about flagging it as high priority. What is that about?
Rachel: Oh yes, our compliance rules say we need to treat applications with high risk countries first, in case we think there is any illegal activity going on.

Tara goes to the board and adds two purple cards. These represent Consequences. Consequence are outcomes that we expect to happen when the scenario finishes successfully. The first consequence is that the review should end up in the senior analyst's todo list. If this doesn't happen, no matter how nice the screens are, the feature will be delivering no value.

This isn't to say that Franky's design ideas have no value - they most certainly do. But diving into UI design too early will take time away from exploring other paths that the user could take, or other business rules or constraints that might apply. Feature mapping is a breadth-first approach - we want to get a high level understanding across the whole feature. Once we nail this, we can decide what the screens should look like.

The second consequence is that this review should be marked as a high priority review, since we are dealing with a high risk country.

The consequence cards look like this:

She adds these to the right of the yellow step cards on the board. The board now has a series of cards that describes the full user journey for this example, starting with the context (Bill’s business activities), then describing what the user does in business terms (Joe escalates the review).

The team has mapped out a single example, from start to finish, and from inputs to outcomes. This has helped clarify their understanding of Rachel’s narrative story, and answer a few questions they had. The process also highlighted what the real goals of the feature are, beyond the screens that need to be built. But this is just the first step in the feature mapping exercise. Now the real work begins.

You don’t always have to start with the narrative example, especially if it is a rich, complicated one. Sometimes we start with a very simple example, and gradually build complexity in by adding new scenarios that illustrate the rules and constraints we know about, as well as the new ones we discover along the way. This helps us get the momentum going without getting bogged down in details.

Identifying alternate flows

Once the team has mapped out an initial example, they examine each step more closely. The idea is to find alternative ways the story could play out, by looking at each step and asking questions such as “what else could happen here” or “what else could the user do?”

In this case, Tara continues her questions about high risk countries.

Tara: What happens if it is a medium risk country? Can you give an example of one of those?
Rachel: Sure. Suppose Nick imports carvings from Nigeria. Nigeria is considered a medium risk country. The application would still need to be escalated, but it wouldn’t be high priority.

Tara goes to the board and adds another row of cards to represent this scenario:

This new example explores the case of Nick and his Nigerian carvings. The steps are similar to our first example, and we finish with the same initial consequence. But this time, the second consequence is that the review should be normal priority, not high.

Grouping by Business Rules

In most cases, the examples we find are concrete illustrations of business rules or high level acceptance criteria. In a feature map, we show this relationship with a special “business rule” card.

Rachel: I think this covers the first business rule for this story, which was “People with financial dealings with high or medium risk countries should be escalated”

Rachel adds some more cards to the board to complete the picture. First, a blue card to represent the business rule. This goes to the left of the green example cards. She also adds some yellow cards above the first two steps. These act as titles for the individual steps.

The complete Feature Map now looks like this:

But David isn’t so sure that all the angles have been considered.

David: It certainly covers the country risk aspects. But what does “people with financial dealings” mean? What is that about?
Rachel: A business owner or director would be considered to have financial dealings, but an employee would probably not, unless they have some financial role. For employees, escalation would be optional.
David: OK, so what happens with Anna, Bill’s accountant.
Rachel: Well, Joe would have the option of escalating, but he wouldn’t have to. He might just place a note to ask Anna some questions about her work. But if he doesn’t escalate the review, the account should be automatically flagged for review in six months.

This is a new twist to the story. David goes to the board to map it out.

Tara looks at the board again.

Tara: OK, so that’s for a medium risk country. What if it’s a high risk country?
Rachel: Any dealings with high risk companies are escalated and flagged.
Tara: I think that merits another example.

So Tara adds the example of Andrew, Bill’s accountant:

Examples and counter-examples

So far, the team has been concentrating on cases where the high-risk country business rules applies. But positive examples, sometimes referred to as “Happy-Day scenarios”, are not always enough to understand the scope of a requirement. We often need to see a negative case as well as a positive.

Tara: Can you give an example when this rule would not apply?
Rachel: Sure. Say Lucy owns a fashion design company who work with designers in France and Sweden. These are both low-risk countries, so Joe could approve the application directly.

Tara adds this case to the board, which a new rule card:

The complete map now looks like this:

This is just part of a typical feature mapping workshop. By working through examples and counter-examples, the team has isolated a set of key scenarios that illustrate the “high and medium risk country” acceptance criteria. The process is deliberately simple and easy to follow, even for non-technical stakeholders. But the conversations the teams have during workshops like this are invaluable; even with this apparently simple case, they have uncovered rules that they had not considered or known about initially.

Feature Mapping techniques vary from story to story, and the activities are not always done in exactly the order shown here. Later on in this book, we will look at some other ways Feature Mapping can work for different types of requirements.

From Feature Maps to Executable Specifications

We just saw how Feature Mapping helped Rachels team explore the Review Escalation story. Not only did they get an overview of the customer needs, but they also discovered a few edge cases and surprises that might have tripped them up during the development. With teams that practice Feature Mapping, this is a regular occurrence. A Feature Mapping workshop may take a little longer than a traditional Backlog Grooming session. But the time spent pays for itself many times over with the deeper understanding that it gives the team about the problem they are trying to solve.

But the benefits of Feature Mapping do not stop here. They also help teams define more useful, more actionable acceptance criteria, and lead to higher quality automated acceptance tests. Let's see how.

Acceptance Criteria, Automated Acceptance Tests and Living Documentation

We saw earlier how Rachel and Pete had already sketched out some initial acceptance criteria for this story:

• People with financial dealings with high or medium risk countries should be escalated
• People working in a high or medium risk industry should be escalated
• People without a local address should be escalated
• People opening an account with large amounts of cash should be escalated
• Blacklisted customers should be refused immediately

But these were only a starting point. In the previous section, we saw Rachel and her team work through a Feature Map covering the first acceptance criteria, about high and medium risk countries. They fleshed out the main scenarios into more concrete examples, but also come up with counter-examples and outcomes which hadn't been mentioned in the initial acceptance criteria.

The benefits of Feature Mapping don't end when the team leaves the discovery session.

An important part of Behaviour Driven Development is the idea of Executable Specifications, where requirements are written in a form that is both easy to understand for the business, and that can be executed as part of the automated test suite. In the figure below you can see an example of this sort of report which can act as both functional documentation and as an automated test. Rachel uses automatically generated reports just like this one demonstrate that each new feature works as expected, and in turn to get the features into production faster.

And, as we will see, Feature Mapping makes it very easy to turn acceptance criteria into automated acceptance tests that can generate this sort of living documentation.

From Acceptance Criteria to Executable Specifications

At Rachel's company, they understand the value of test automation, and management wanted to see automated tests for as many stories as possible. But when Rachel's team started out, they struggled. Sure, they wrote lots of test scripts using Cucumber and Selenium. But they never could seem to get a fully passing set of tests. There were always seemingly random test failures, and Tara couldn't present the results to management as evidence that the application worked correctly. And the maintenance overhead was huge - Tara seemed to spend a third of her time just updating the Cucumber scenarios to reflect the latest changes in the UI.

Their Cucumber scenarios typically looked something like this one:

Scenario: Check that large cash deposits are escalated
  Given I log on to the application
  And I click on the Monitoring Dashboard button
  And I select the Open Reviews menu
  Then I should see a review for Al Capone
  And the review should have an alert icon
  When I click on the review
  Then I should see an alert for excessive cash deposited
  And I should see the "Approve/Escalate" button

This scenario has many flaws. Cucumber scenarios are supposed to represent "executable specifications", but with all those "clicks" and "select"s, this one reads much more like a manual test script than a specification. And this makes it hard work for Pete to figure out what business rule is meant to represent, let alone whether it is correct or not.

The scenario is also tightly coupled to the application screens. If the screen components or navigation changes, this scenario may need to be updated as well, even though the underlying business logic hasn't changed.

Rachel and her team have learnt the hard way that poorly written automated acceptance tests like the one above quickly become an expensive liability, taking considerable time and effort to maintain.

Feature Maps help write better executable specifications

Feature Mapping helped the team change the way they thought about these scenarios. Feature Mapping offers a clean, natural path to high quality automated acceptance tests. They are easy to express in the Given-When-Then notation used by popular BDD tools like Cucumber and SpecFlow.

For example, the first row of the Feature Map developed by Rachel's team describes the case of high-risk countries:

After the Feature Mapping session, Tara and David work together to convert the examples they identified into the Given-When-Then format.

Feature: Escalating a Review for high or medium risk countries

In order to ensure that new customers are reviewed by the most appropriate person
As a compliance officer
I want complicated cases to be escalated to a senior analyst

Joe is a junior analyst
Sally is a senior analyst

Background:
    Given Bill owns an import business that imports carpets from Iran

Scenario: Escalating a customer with dealings with a high-risk country
  Clients with dealings with high or medium risk countries should be escalated

  Given Bill has asked Joe to open a business account
  When Joe is prompted to escalate the review
  And he escalates the review
  Then the review should be placed in Sally's review list
  And the review should be flagged as high priority

Notice how almost every card has a corresponding element in the Given-When-Then scenario. The text reads smoothly and business folk would be able to understand it easily. And since the business rule is described in solution-agnostic terms, the scenario will remain true even if the underlying implementation changes. This is an important part of writing stable, maintainable automated acceptance tests.

We will discuss good test automation practices, and how Feature Mapping encourages and enables them, in the later chapters of this book.

Conclusion

Feature Mapping is an intuitive, easy-to-understand way for business stakeholders and team members to discuss the rules and constraints around specific user requirements. It helps teams ask the right questions and explore variations and constraints to build a deeper understanding of the problem they are solving. It helps business stakeholders articulate and prioitise different aspects of a requirement, and it helps team members understand how a feature will deliver value. This all in turn helps the teams more valuable features sooner.

We also saw how Feature Maps lead naturally to clean and readable automated acceptance tests, helping teams avoid many of the traps of poorly-written BDD scenarios and hard-to-maintain test suites.

Feature Mapping is a flexible approach that works in many different contexts, and at many different levels. Now that we have covered the basics, we can look at some of these. In the following chapters, we will look at how Feature Mapping is used in a variety of real-world problem domains. But before we do, let's take a closer look at the various elements that go into a Feature Map.

Next Steps

If you would like to learn more about Feature Mapping, and improve your skills in Agile Requirements Discovery and BDD, make sure you check out our new deep-dive BDD video training module.

The training will show you how to:

• Help your team collaborate more effectively, applying cutting-edge facilitation techniques to dial in on what your users really need;
• Identify and express acceptance criteria and scenarios quickly and efficiently;
• Know what scenarios you should write, and how to write them so they give you the highest coverage and business folk the most confidence;
• Reduce defects and unnecessary rework and speed up delivery as well!

And when you master these techniques, you'll find test automation quicker and easier to implement as well!

👉 Click here to check out the Agile Requirements Discovery Deep Dive Training