Understanding the business goals: Feature Injection and related techniques - What do I want? Defining requirements using BDD - BDD in Action: Behavior-Driven Development for the whole software lifecycle (2015)

BDD in Action: Behavior-Driven Development for the whole software lifecycle (2015)

Part 2. What do I want? Defining requirements using BDD

BDD principles are applicable at all levels of software development, from requirements discovery and definition right through to low-level coding and regression testing. Part 2 of this book focuses on the first aspect of BDD: how BDD is used to discover and describe the features you need to build. Part 2 is written for the whole team.

In chapter 3, we’ll take a step back. You’ll see how important it is to consider and understand the business motivation and value behind the software you’re asked to deliver. You’ll learn how to discuss the relative value of proposed features and use these discussions to determine what features to build, and, more importantly, what features not to build. This is at the heart of building the right software.

In chapter 4, we’ll go into more detail. You’ll learn how BDD teams collaborate to discover, describe, and define the features they need to deliver. You’ll discover how to explore the scope and detailed requirements of a feature using conversation and concrete examples, and how these conversations can change your understanding of the features you’re trying to define.

In chapter 5, you’ll learn how to formalize the examples we discussed in chapter 4 in a clear, unambiguous form that we’ll refer to as executable specifications. This too is a collaborative process; as you’ll see, the act of expressing the examples in a more rigorous form helps eliminate ambiguities and assumptions around the requirements, and it also paves the way for automation.

Finally, in chapter 6, you’ll learn about tools that you can use to automate these executable specifications in different environments and languages, including Java, .NET, Python, and JavaScript. Automation is an important part of BDD; it forms the basis of the automated acceptance criteria that verify the features being delivered and of the living documentation that illustrates and documents these features.

At the end of part 2, you should have a solid understanding of why and how BDD teams collaborate to discover and define the features they need to deliver, and you’ll be able to express the acceptance criteria around these features in the form of executable specifications.

Chapter 3. Understanding the business goals: Feature Injection and related techniques

This chapter covers

· High-level requirements-analysis techniques

· Using Feature Injection to identify business goals and supporting features

· Visualizing high-level requirements with Impact Mapping

· Identifying stakeholders and their roles

Before you can implement a software solution, and before you can even judge what features you should implement, you need to understand the problem you’re solving and how you can help. Who will be using the system, and what benefits will they expect from it? How will your system help users do their jobs or provide value to your stakeholders?

How can you know if a particular feature will really benefit the organization as you suppose it should? Are you building software that will have a measurable, positive impact for your client’s business? Will your project make a difference? Sometimes a particular feature, or even a particular application, shouldn’t be implemented because it will clearly not deliver the business benefits expected of it.

This makes for a lot of unknowns. And as we discussed in chapter 1, you’ll rarely understand the requirements completely or correctly at the start of a project, and requirements and assumptions often change during the life of a project. It’s unproductive to try to draw up detailed specifications in the initial phases of a project, when you know relatively little about it: this just sets you up for rework later, when the requirements, or your understanding of them, inevitably change. Instead, you should try to build a deep understanding of the business context behind the project so that you can react appropriately to change and remain focused on delivering the value that the business expects from the project. This is what we’ll focus on in this chapter (see figure 3.1).

Figure 3.1. In this chapter we’ll focus on discovering the features that will add real value to the business.

BDD places great emphasis on building “software that matters” and defines several processes for turning client requirements into something that developers can use to code against and that accurately reflects the core values of the software the client wants.

To ensure that the team is focusing on building valuable features, business analysts will find it useful to identify four things:

1. Why is the software being built (what is the project’s vision statement)?

2. How will the project deliver value to the organization (what are the project’s business goals)?

3. What stakeholders are involved in the project, and how will the project affect them?

4. What high-level capabilities should the software provide for stakeholders to enable them to achieve their business goals more effectively?

Techniques such as Feature Injection, Impact Mapping, and the Purpose-Based Alignment Model can help identify how the project will benefit the organization and what features can best realize those benefits:

· Feature Injection takes BDD beyond scenarios and stories and can help you discover what features you really need to satisfy the underlying business goals of a project.

· Impact Mapping helps you identify and visualize the relationships between business goals, stakeholders, and features.

· The Purpose-Based Alignment Model can help you judge how much effort you should put into different features.

But before you learn about all this, it’s time to meet the (imaginary) client you’ll work with throughout the rest of the book: Flying High Airlines.

3.1. Introducing Flying High Airlines

Flying High Airlines is a large commercial airline that runs both international and domestic flights. Flying High has been under pressure due to increasing costs and competition from low-cost carriers, so management has recently launched a new and improved version of their Frequent Flyer program to try to retain existing customers and attract new ones. This new program will offer many compelling reasons to join; like all Frequent Flyer programs, members will accumulate points when they fly, but members will also benefit from many exclusive privileges, such as access to lounges and faster boarding lines, and they’ll be able to easily spend their accumulated miles on flights and on other purchases for themselves or their family members.

As part of this initiative, management wants a new website where Frequent Flyer members can see their current status in real time, redeem points, and book flights. The existing system just sends out paper account statements to members each month to tell them how many points they’ve accumulated. In addition, the Flying High call center is currently overloaded with calls, as Frequent Flyer members can only benefit from their member privileges and use their accumulated points if they book over the phone. Management hopes that being able to book directly online instead of over the phone will encourage Frequent Flyer members to book more often with Flying High.

In this chapter, and throughout the rest of the book, we’ll use examples from this project to illustrate the concepts and techniques we discuss.

3.2. Feature Injection

The overarching approach we’ll discuss in this chapter is called Feature Injection. Feature Injection is an approach that tries to identify the value that a project is meant to deliver and the features that will be able to deliver this value.[1] Initially elaborated by Chris Matts, and since championed by Liz Keogh[2] and other members of the BDD community, Feature Injection distills many techniques and approaches that BDD practitioners apply and have found useful in the wild. Feature Injection provides teams with a framework that helps focus BDD efforts on those features that will deliver real business value.

1 See, for example, Chris Matts and Gojko Adzic, “Feature Injection: three steps to success,” InfoQ (Dec. 2011), http://www.infoq.com/articles/feature-injection-success.

2 Liz Keogh, “Pulling Power: A New Software Lifespan” (2009), http://www.infoq.com/articles/pulling-power.

The aim of Feature Injection is to flesh out the minimum set of features that will provide the most benefit to stakeholders in terms of achieving their business goals. Feature Injection emphasizes the importance of engaging in an ongoing conversation with stakeholders in order to progressively explore, elaborate, and expand on a shared understanding of what needs to be delivered and why. It revolves around a simple three-step process (see figure 3.2):[3]

3 Kent McDonald and Chris Matts, “Feature Injection: A Gentle Introduction,” Agile 2009 Conference, http://agile2009.agilealliance.org/node/185/.

Figure 3.2. Feature Injection involves a three-step process: hunt the value, inject the features, and then spot the examples.

1. Hunt the value.

2. Inject the features.

3. Spot the examples.

3.2.1. Hunt the value

Many Agile teams build up a large list of user stories (often referred to as a backlog), and then prioritize the stories to decide which features they really need to build in the next iteration. But sifting through stories to find the high-value ones takes time and effort, especially as the list of stories grows longer. Wouldn’t it be easier if the stories you don’t really need weren’t placed in the list in the first place?

Feature Injection does things the other way round. In Feature Injection, you start by trying to clarify exactly how you expect the system to deliver business value, and only then do you identify the features that might best deliver this outcome. This makes it easier to focus your work on the features that will deliver the best return on investment. This is what’s called “hunting the value.” The aim is to understand the business value that lies behind a feature so that you can objectively decide which features are really worth creating.

Teams that use Feature Injection use a number of techniques that help model the relative value of features in terms of the business value they can provide. Don’t be afraid of the word model: the best models are actually pretty simple. In Impact Mapping, for example, you use a simple mind-mapping approach to identify and compare the relative value of features, mapping them back to their underlying business goals. The Purpose-Based Alignment Model is another graphing technique that can help you decide how much effort you should invest in each feature. Models make it easier to discuss the assumptions that underlie the value proposition of each feature, and they prevent low-value features from slipping in unnoticed.

We’ll look at several of these models and techniques in more detail later in this chapter.

3.2.2. Inject the features

As you’ve seen, once you’ve identified the goals of your project and how it’s expected to deliver value to the business, you can objectively decide what features are worth including in the application. But you can do better than that. A team practicing Feature Injection doesn’t just decide what features in the product backlog are worth doing; they proactively look for features that will deliver business value.

One of the fundamental tenants of Feature Injection is that the value of a piece of software generally comes from the outputs. For example, the value of an application comes from the information it provides, the sales that result from its use, or the reports it generates that allow users to make decisions. It comes from the financial transactions that it processes or from the sold products it ships. Value is to be found not in the inputs, but in the outputs.

When you want to know what features will deliver the most value, or the most return on investment, you should start with the outputs or outcomes. Take the outputs that will deliver the most value, and work back to find the minimum set of features you need in order to produce these outcomes. For example, you might identify the following features that could contribute to the goal of increasing sales revenue:

· Increase sales by allowing Frequent Flyer members to purchase flights with redeemed miles.

· Increase sales by allowing travellers to book flights online.

Again, this is quite similar to the Impact Mapping approach, where you start with a business goal and work back to discover the features that could deliver this goal.

3.2.3. Spot the examples

When you inject features this way, you only get a partial view of how a feature might work. A high-level feature description such as “Purchase flights with redeemed miles” or “Book a flight online” only gives a superficial idea of how a feature should behave. When it comes to implementing such a feature, you obviously need to know more.

Once you have a high-level set of features that you want to implement, you need to expand your understanding so that you can cater for the variety of inputs or behavior that may affect the outcomes. In other words, you need to expand the scope of the features that you’ll build until you’re satisfied that they’ll deliver the business value you expect of them.

In Feature Injection, you use high-level examples to flesh out this missing scope. As you’ll see, examples are a very effective way to communicate ideas about a problem domain and to discover and clarify what you don’t know. Examples are intuitive and easy to understand, and they help flush out assumptions and misunderstandings. They can help you discover areas that need further investigation. They also act as the basis for more in-depth analysis, using both traditional business analysis techniques and more collaborative approaches.

We’ll look at techniques and practices that can help in each of these stages in this chapter and the next. But before we do so, let’s look at some of the terms we’ll use.

3.2.4. Putting it all together

In a nutshell, Feature Injection involves discovering exactly how a system is expected to contribute value to the business and using real-world examples to determine the minimum set of features that will allow stakeholders to deliver this value. You can see how these ideas are interconnected in figure 3.3.

Figure 3.3. All features, and ultimately all code, should map back to business goals and the project vision.

At the highest level is the project vision, a short statement that provides a high-level guiding direction for the project. This statement helps ensure that all the team members understand the principal aims and assumptions of the project. For the Flying High Frequent Flyer website, the vision could be to create a website that will enable Frequent Flyer members to consult and use their points and membership privileges more quickly and more easily than with the current manual system.

More precisely, a project aims to support a number of business goals. Business goals are executive-level concepts that generally involve increasing revenue, protecting revenue, or reducing costs. For the Flying High Frequent Flyer website, one of the primary business goals might be “Earn more ticket sales revenue through repeat business from Frequent Flyer members.”

As a software developer, your job is to design and build capabilities that help the business realize these goals. A capability gives your users the ability to achieve some goal or fulfill some task, regardless of implementation. Liz Keogh says that a good way to spot a capability is that it can be prefixed with the words “to be able to.” For example, Flying High Frequent Flyer members need the capability to be able to book flights and benefit from their member privileges while doing so.

Tip

Capabilities don’t imply a particular implementation. For example, “the ability to book a flight” could be provided online or over the telephone.

You design and implement features to deliver these capabilities. Features are what you actually build, and they’re what deliver the value. One feature that helps deliver the capability to book flights might be “Book flights online using Frequent Flyer points.”

Tip

Features are pieces of deliverable software functionality, such as an “Online Frequent Flyer account summary.”

To build up your understanding of the features, you can use concrete examples of what the system should do in different situations. These examples can form the basis for the acceptance criteria of a feature. Once you have a set of features and scenarios to work with, you can start designing a user interface and writing the code that goes behind it.

Tip

Examples illustrate how a feature works, such as “Account summary should display a list of recently earned points.”

Of course, the process is not as straightforward and linear as it might appear here. Feature Injection is a very iterative process. You try to identify the features that will provide the most business value, represent the most significant risks, or reduce your ignorance. You build and deliver these, and see what you can learn in the process. Then you adjust your assumptions based on this feedback, and repeat the cycle.

3.3. What do you want to achieve? Start with a vision

The first step in Feature Injection is “hunt the value.” But it’s much easier to identify the value that you expect out of a project if you have a clear idea of the overall vision of the project.

Suppose I was to ask you to go and buy me a new power drill for some DIY jobs I need to do around the house. I’m not sure how much a power drill costs these days, but I certainly don’t want to spend more than I have to. A red one would be nice, as it would go with my red toolbox.

Being an obliging sort of person, you drive down to the local hardware store and take a look at the range of power drills on display. But without a bit more background, you’d be hard put to make me happy. If I’m trying to assemble a large bed with a lot of screws, a small and inexpensive cordless electric drill, or maybe even a cordless screwdriver, should suffice, and a heavier model would just be cumbersome. On the other hand, if I’m going to install some new shelves on a brick wall in my garage, I’ll need a more powerful hammer drill as well as a set of masonry drill bits and some screw anchors. If the garage has no power outlets, the drill will have to be of the more expensive cordless variety.

To get things done effectively, you need a clear understanding both of what you’re trying to achieve and of the ultimate goal or purpose of your work. Studies have demonstrated that team collaboration improves significantly when members share a clearly identifiable goal.[4] This is equally true for software development. If you are to deliver effective solutions for the problems your clients face, you need to understand the underlying business goals.

4 Panagiotis Mitkidis et al., “Collective-Goal Ascription Increases Cooperation in Humans,” PLOS ONE (May 2013) 8:5, http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0064776.

Exercise 3.1

In the previous chapter, you worked on a timetable application to publish timetables and real-time data feeds for train lines. That client also subsidizes bus companies for the bus trips they run. Currently, the bus companies send in paper forms detailing the bus trips they do each month, and they’re paid on this basis. Management now wants you to write an application that keeps track of the real-time bus data and matches it against the subsidy requests that the bus companies send in. Try to articulate the business goals for this project in a few short sentences.

3.3.1. The vision statement

One useful way to express what a project is supposed to achieve is to write up a vision statement. A vision statement outlines the expected outcomes and objectives of the project in a few concise and compelling phrases. It gives the team an understanding of what they’re trying to achieve, helping to motivate them and focus their efforts on the essential value proposition of the product. It provides a beacon for all to see, helping teams align their direction and concentrate their efforts on building features that actively contribute to the project’s goals.

Tip

The vision statement should be simple, clear, and concise—short enough to read and assimilate in a few minutes. It should also be intimately familiar to the whole team. Indeed, in the midst of an iteration, when requirements are changing quickly and frequently, it’s all too easy for teams to get sidetracked by minor details, and the vision statement can remind them about the broader goals of the project.

A good vision statement will focus on the project’s objectives, and not on how it will deliver these objectives. It won’t go into details about what technology should be used, what timeframe the project delivery should respect, or what platform it should run on. Rather, it presents the project objectives in the context of the problem the project is trying to address.

Most traditional projects generally do have a vision of some sort. Executive managers usually know, at least in the back of their minds, what they expect out of a project in terms of business value, or they wouldn’t have approved it. By the nature of their jobs, executives usually have a very keen understanding of how a project is expected to contribute to the bottom line. Despite this, they may not have articulated the expected outcomes in a way that can be easily shared with the development team.

Larger organizations typically require some sort of formal documentation that explains the business case and scope of a project, and this document will usually contain a vision statement of sorts. But these are often dry, rigid documents, written to respect the local project management process requirements, and they’re relegated to a project management office once the project has been signed-off on. They’re the realm of project managers and project management offices (PMOs). In many cases, these documents never make it to the development team, which effectively renders them useless as vision statements in the Agile sense. Indeed, how can a shared vision be useful if not everyone can see it?

3.3.2. Using vision statement templates

A project vision statement need not be a long and wordy document. It can be a succinct paragraph that sums up the focus of the project in one or two sentences. In his book Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers (Harper Business, 2002), Geoffrey A. Moore proposes the following template for a good product vision statement, which I’ve often heard mentioned in Agile circles:

For example, the vision statement for Flying High’s Frequent Flyer program might go something like this:

FOR travellers

WHO want to be rewarded for travelling with Flying High Airlines

THE Flying High Frequent Flyer program IS A loyalty program

THAT lets members easily and conveniently view and manage their accumulated

points in real time, and spend their points for real purchases with

unequaled ease.

UNLIKE other airline Frequent Flyer programs,

OUR PRODUCT lets members use their points easily for any sort of online or

brick-and-mortar purchase.

This short text sums up who your target audience is, what they want, how your product will give it to them, and how your product distinguishes itself from its competitors. Of course, there’s no obligation to follow this (or any other) template to the letter, but it does provide a good summary of the sort of things that you should consider including in your vision statement.

Writing a viable vision statement can be a tricky exercise, but it pays off over the life of the project. One effective approach to writing a good vision statement is to think in terms of designing a product flyer. In a nutshell, what does your product do? How will the product benefit your organization? Who is your target audience, and why would they buy your product rather than that of a competitor? What are its three or four principal selling points? Discuss these questions with all of the key project players, including users, stakeholders, and the development team. Then try to formulate a vision statement using Moore’s template. If your project team is big enough, you can split up into several cross-functional groups and compare results, refining the statement until everyone agrees.

Exercise 3.2

Write a vision statement for the bus subsidies project from the previous exercise using Moore’s template. How does it compare with what you wrote at the start of this section?

3.4. How will it benefit the business? Identify the business goals

Once you have a clear idea of the project vision, you need to define the underlying business goals that drive the project and contribute to realizing this vision. A business goal succinctly defines how the project will benefit the organization or how it will align with the organization’s strategies or vocation.

All projects have business goals; otherwise management wouldn’t have approved them in the first place. But not all projects have clearly defined and visible business goals. And projects with well-defined and well-communicated business goals have a much better chance of success than those that don’t. A recent university study found that teams with a clear common understanding of their goal cooperated better and worked more effectively.[5]

5 Panagiotis Mitkidis et al., “Collective-Goal Ascription Increases Cooperation in Humans,” PLOS ONE (May 2013) 8:5, http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0064776.

Understanding these goals is even more important when unforeseen issues arise, when technical challenges make implementing a particular solution harder than initially thought, or when the team realizes they’ve misunderstood the requirements and need to do things differently. If developers are expected to respond appropriately to this sort of challenge, they need to have a solid understanding of what business value is expected from the system.

At the end of the day, business people want the software being built to help them achieve their business goals. If the software delivers in this regard, the business will consider it a success, even if the scope and implementation vary considerably from what was originally imagined. But if the software fails to meet the underlying business goals, then it will rightly be considered a failure, even if it meets the requirements provided by the customers down to the letter.

3.4.1. Writing good business goals

Business goals are high-level statements that focus on business value or opportunity, statements that executives would be able to relate to and discuss. For example, one of the more important business goals for the Frequent Flyer program discussed earlier might be the following:

Increase ticket sales by 5% over the next year by encouraging travellers to

fly with Flying High rather than with a rival company.

A statement like this has the merit of clarifying the “why” of the project: why exactly are you building this software? But like the project vision, business goals are often very poorly communicated. Many development teams have only a vague notion of the business goals they’re trying to deliver. And yet, understanding these goals is essential to making correct scope, design, and implementation choices during the project.

You can also write goals using the following “In order to ... As a ... I want to ...” format:

In order to increase ticket sales by 5% over the next year

As the Flying High Sales Manager

I want to encourage travellers to fly with Flying High rather than with a

rival company

This is a variation on the more traditional “As a ... I want ... so that ...” form used in many project teams for story cards. This form puts the goal first (“In order to ...”) as opposed to the more traditional user story format, where the stakeholder is placed in the primary position. Putting the goal first places the emphasis on the expected outcome, which should be of obvious value to the business. When the stakeholder comes first, the last section (“so that ...”) tends to be eclipsed, and you may find yourself proposing high-level capabilities and then struggling to justify them with a solid business goal.

This is a very versatile format, and you’ll use it to describe requirements at various levels of abstraction throughout the book.

Whatever format you prefer, a good business goal should be precise. Some business managers use the SMART acronym: business goals should be

· Specific

· Measurable

· Achievable

· Relevant

· Time-bound

First and foremost, a goal should tell readers specifically what you’re trying to do (“encourage travellers to fly with Flying High”). But it should also describe why you want to do this and outline the business benefits you’re trying to achieve by doing so (“increase ticket sales”).

A goal should also be measurable. A measurable goal will give you a clearer idea of business expectations and also help you determine whether it has been achieved once the work is done. You can make a goal measurable by introducing notions of quantity and time. For example, “Increase ticket sales by 5% over the next year.”

Quantifying a goal in this way will also make it much easier to determine how best to approach the problem, or whether the goal is even achievable in the first place. Increasing sales by 200% in 6 months would be quite a different proposition than increasing by 5% over the next year. Knowing the timeframe (6 months) also makes the goal more tangible and focused. In all of these cases, precise figures help manage expectations and ensure that everyone is on the same page.

But possibly the most important attribute of a good goal is its relevance. A goal is relevant if it will make a positive contribution to the organization in the current context within the specified timeframe, and if it is aligned with the overall strategy of the organization. Relevant goals are goals that will make a difference to the business.

3.4.2. Show me the money—business goals and revenue

Let’s take a closer look at the business goals behind the Frequent Flyer program. A more complete list of goals might include the following:

· Increase ticket sales revenue by 5% over the next year by encouraging travellers to fly with Flying High rather than with a rival company.

· Increase the customer base by 10% within a year by building a positive image of the Frequent Flyer program.

· Avoid losing existing customers to the new rival Hot Shots Frequent Flyer program.

· Reduce hotline costs by enabling Frequent Flyer members to purchase flights with their points directly online, unlike the current program, where travellers need to call to make a booking.

Notice that the preceding goals all seem to boil down to earning more money, either by increasing revenue or by reducing costs. The goals of most commercial organizations are, by definition, ultimately financial in nature. In fact, almost all business goals can be grouped into one of the four following categories:

· Increasing revenue

· Reducing costs

· Protecting revenue

· Avoiding future costs

For example, “Increasing ticket sales revenue by 5%” (the first of the goals previously listed) is clearly about increasing revenue by selling more tickets. The second, “Increase the customer base by 10% within a year” is similar, though the connection with generating revenue is slightly more indirect. “Avoid losing existing customers” is an example of protecting revenue, whereas the fourth, “Reduce hotline costs,” is clearly about reducing costs.

An example of avoiding future costs might be implementing certain reports that will be required by new legislation due to take effect next year. In this case, you’re investing effort now in order to avoid fines for noncompliance in the future.

Business goals in a public service organization—Transport for NSW

Transport for NSW, the government agency responsible for public transport in New South Wales, Australia, recently implemented a project to provide Google Maps with real-time scheduling information for trains and buses, as is done in many large cities around the world. Travellers can use Google Maps not only to find public transport options between two locations, but also to find out when the next bus or train is scheduled to arrive, based on real-time data coming from the buses and trains.

There’s no profit motivation here: the aim is to allow public transport passengers to be able to use the public transport network more efficiently and reduce the time passengers need to wait for public transport. The motivation behind this may be increasing customer satisfaction. Happier passengers are more likely to use this service instead of any alternatives. A secondary goal could be to save people time, freeing them up for more productive work, which in turn benefits the local economy. This project will generate no increased revenue for the government agency implementing the project.

This rule still holds true for government or non-profit organizations, but in a slightly modified form. Public services, for example, are not as interested in generating revenue as they are in providing valuable services to the public. This type of organization also typically has an externally defined budget: the service is responsible for how taxpayer dollars are spent, so cost plays a critical role in business goals. In general, the business goals for projects in non-profit organizations tend to fall into the following categories:

· Improving service

· Reducing costs

· Avoiding future costs

Exercise 3.3

Identify some business goals that might be applicable to the bus subsidies project in the previous exercise. Propose concrete strategies to measure how well the application discussed in exercise 3.1 achieves these goals.

3.4.3. Popping the “why stack”: digging out the business goals

If you want to build software that delivers real value to your customers, understanding the core business goals of a project is essential. Unfortunately, neither business sponsors nor end users typically express their needs in terms of pure business value. Instead, they talk in terms of concrete features or solutions that they have in mind. In addition, stakeholders are rarely capable of providing all the requirements up front, even if they do know them ahead of time.

Stakeholders in large organizations have often been trained to believe that they must provide a detailed list of all their requirements at the start of a project. In traditional Waterfall-style projects, once the requirements have been signed-off on, the project management process deliberately hinders any changes, corrections, or additions that users might want to make: this is known as change control. This dissuasive change-control process tends to result in very large sets of requirements full of everything the stakeholder can possibly think of, with many features being included just because they “might come in handy” someday.

It would be easy to take the feature requests that come out of such a process at face value. After all, shouldn’t the users know better than anyone else what they want? Why not just note down what they want, and then do it? There are two very good reasons why this would be a bad idea.

First, the people who produce these requirements—the business sponsors, the end users, and so forth—are typically not well versed in the technologies that will be used to deliver the solution. The features they request may not be optimal from a technical viewpoint (there may be better ways of getting the job done), from a usability perspective (they are not UX experts), or from a financial one (you may be able to get the job done faster and cheaper using a different approach). The development team has a professional responsibility to propose the most appropriate solution for a given problem. But if the business goals are not clearly expressed and understood, you’ll be hard put to suggest potentially more appropriate solutions.

But there’s a second reason that’s arguably even more important than the first. If you don’t know why you need to deliver a feature in a particular way, you’ll have no way of knowing whether this feature is still useful or relevant when change happens.

Any software project is an exercise in ongoing learning. Things inevitably change along the way, including assumptions and even the team’s understanding of how a particular feature might benefit the business. A requirement that’s expressed in the form of a detailed technical solution is embedded in a fabric of assumptions and preconceptions. You can be sure that some of these assumptions will turn out to be incorrect, or will change along the way, but it’s hard to predict which ones will be wrong. When changes do happen, you need to be able to reassess the relevance of the features that you’re building, but if you don’t know why the business wants a feature, this will be much more difficult.

You usually need to drill down a little to discover what the business really needs. One of the best ways to do this is to repeatedly ask “why” until you get to a viable business goal. As a rule of thumb, five why-style questions are usually enough to identify the underlying business value (seefigure 3.4).

Figure 3.4. It’s always important to understand why you’re undertaking a project.

Let’s look at a practical example. Suppose you’re working for a large media corporation. The director of marketing has come to you with a requirement that seems simple enough on the surface: “I want people to be able to post their printed classified ads online.” To learn a little more, you might respond with something along the following lines: “I am but a humble developer, unversed in the art of newspaper advertising. Why do you need to enter the classified ads online?”[6] To which, the marketing director replies, in a slightly annoyed tone, “Because people don’t read the classifieds anymore; they prefer to go online.”

6 OK, so you might skip the first bit.

Objective-driven management

Don’t tell people how to do things, tell them what to do and let them surprise you with their results.

George S. Patton

General George S. Patton was a very successful American general known for his achievements in the European theater during the Second World War and for his unconventional and dynamic leadership style. Patton was once asked at a press conference how he was able to get such outstanding competence and devoted loyalty from his staff. “I never tell people how to do things,” replied Patton. “I tell them what to do but not how. If you give people responsibility, they will surprise you with their ingenuity and reliability.”

At this point, you still haven’t really identified any value that the requested system might deliver, so you could follow up with another question: “Why is that a problem for us?” To which the director relies, “Because revenue from the classified ads service is falling.”

So now at least you’re talking about financial impact. Because you’re still getting answers, you might press your luck a bit further: “And why will entering the ads online stop our classified ads revenue from falling?” To which the director answers, “Because more people will be able to browse our classified ads online.”

“So, to make sure I have the whole picture,” you reply, “how will more people seeing our ads online stop our classified ads revenue from falling?”

“Well, if more people can browse the ads online, the products are likely to sell faster. We earn a commission on each sale, so the faster the products sell, the more we earn.”

So here we have a clear mapping back to a measurable business goal: you want to place the ads online so that more people will see the ads and hopefully purchase the advertised goods. Because the company earns a commission on each item sold, this will increase the classified ads revenue.

This process, sometimes known as “popping the why stack,” is a powerful analysis tool. Discovering and crystalizing the value proposition behind the features that users ask for not only helps you understand why they’re asking for these features but also puts you in a position to evaluate their relative value and to adapt them to changing circumstances.

We’ll develop this concept further in the next chapter. But first, let’s look at how you can discover what capabilities a system will need to realize its business goals.

Exercise 3.4

Management has asked for a feature that can send SMS alerts to managers whenever a bus company claims to have run more trips than they did according to the real-time data. Team up with a colleague, with one person playing the role of the business stakeholder. Use the “popping the why stack” approach to identify the underlying business goal. Once you’ve identified a goal, discuss whether this is the only or best way to deliver this goal.

3.5. Impact Mapping: a visual approach

In Feature Injection, the “hunt the value” step involves identifying how your project will deliver value to the organization. In the second step, “inject the feature,” you flush out the features that can deliver this value. In his book Impact Mapping (Provoking Thoughts, 2012), Gojko Adzic describes an interesting, visually-based approach to the problem of aligning the software features you deliver with the underlying business goals.

Impact Mapping is a way of visualizing the relationship between the business goals behind a project, the actors that will be affected by the project, and the features that will enable the project to deliver the expected results. Impact maps are simple to create and easy to understand, and they can be a very useful tool for documenting business goals and validating assumptions. This makes them a great place to kick off the requirements-analysis process and to get a high-level view of what you’re trying to achieve.

An impact map is a mind-map built during a conversation, or series of conversations, between stakeholders and members of the development team. The conversation centers around four types of questions:

· Why?

· Who?

· How?

· What?

The first question you need to ask is why you’re building the software in the first place. Or, in other words, what are the underlying business goals you’re trying to achieve? This corresponds to the business goals we discussed earlier.

Visually, each impact map starts with a single business goal at its center. For example, using our Frequent Flyer example, you might start with the first goal, “increase ticket sales revenue by 5% over the next year by encouraging travellers to fly with Flying High rather than with a rival company.” This would be the first node in your impact map, as illustrated in figure 3.5.

Figure 3.5. An impact map starts with the business goal you want to achieve.

In Impact Mapping, the second question to ask is who. Who are the stakeholders impacted by the project? Who are the users of the product? Who will benefit from the outcomes? If you’re selling something, who are your customers? Who will be in a position to cause or influence the outcome you’re trying to achieve? Who can prevent your project from being a success?

This is an area of requirements analysis that’s often overlooked or skimmed over with a few token user roles. But the best-designed feature in the world will be of little value to the business if the users never use it or don’t use it in the anticipated way. Stakeholders have their own motivations and agendas, which can be different from those of the project, and which you need to understand in the context of what you’re trying to deliver. Oftentimes, to achieve a business goal, it’s not enough to write software: you must also succeed in changing people’s behavior.

Of course, one of the most important stakeholders in almost any project is the customer or end user. For example, the Frequent Flyer website will only be a success if it can encourage travellers to become Frequent Flyer members and book more flights with Flying High airlines. To do this, you’ll need to understand and address the needs of your existing and potential customer base and deliver features that address these needs. If you’re building an internal application for internal users, you’ll need to understand what features will enable your users to help achieve the higher-level business goals in the most efficient way possible.

But customers and end users are not the only stakeholders that you need to consider. Executives will be interested in how the project helps them meet their business objectives. System administrators may have security and architecture constraints that need to be catered to, and so on.

For the Frequent Flyer project, you could identify several significant stakeholders who might have an influence on the “increase sales” business goal. For the sake of simplicity, let’s focus on two: existing Frequent Flyer members and call center staff (see figure 3.6).

Figure 3.6. The second layer of an impact map investigates who will benefit from, or who can help achieve, the business goal. It should also include anyone who might be in a position to prevent this goal from happening.

The next question to ask is how. How can stakeholders and users contribute to achieving the business goals? How could their behavior or activities change to better meet these goals? How could you make it easier for them? How might they or their behavior prevent or hinder these goals from being met, and cause the project to fail?

Here you’re thinking about how the system might make it easier for stakeholders to contribute to the business goals, or how you can influence their behavior and encourage them to do so in other ways. You’re expressing things from the point of view of the stakeholder, which emphasizes that you’re trying to write software that’s going to change the way people do things, preferably in a positive way for the business. For example, to increase ticket sales revenue, existing Frequent Flyer members could buy more tickets, but they might also encourage their friends to join, who would in turn buy more tickets.

Telephone sales are time-consuming and costly. Reducing the time taken to sell a ticket over the phone could also contribute to increasing sales revenue by reducing the number of call center staff required.

You could illustrate these concepts in the impact map as shown in figure 3.7.

Figure 3.7. How can these stakeholders help achieve these goals?

The last type of question you need to ask is what. What can your application do to support the impacts you’ve listed in the previous three stages? Or are there other ways to achieve these results without using software? In the context of building an application, the “what” corresponds to high-level features. You may need to break these high-level features down into more detailed ones as your understanding of the requirements increases, until you get to a manageable size. In an Agile project, these features are good candidates for high-level user stories or epics. If you’re using a Unified Process methodology, they might become use cases.

In our example, you might encourage Frequent Flyer members to buy more tickets by making it easier to redeem miles on flights or on other products (see figure 3.8). You might make it easier to talk about the great deal they just got with their Frequent Flyer discounts on Facebook or Twitter. And you might reduce the number of telephone bookings by determining what sort of bookings are being done over the phone and making online purchases for these tickets easier.

Figure 3.8. What can you do to encourage or allow the stakeholders to modify their behavior to help achieve the business goal?

Impact Mapping helps you visualize how features and deliverables contribute to a business goal. It also helps underline any assumptions you may be making. For example, here you’re assuming that Facebook and Twitter integration will be enough for Frequent Flyer members to proudly post about all their trips. Impact Mapping encourages you not only to sketch out these relationships and assumptions, but also to define metrics that you can use when the feature goes live to test whether your assumption was correct. In this case, you might keep track of the number of Facebook and Twitter posts that are generated by Frequent Flyer members in order to learn how effective your new social media integration strategy really is.

It’s important to remember that impact maps are not plans: they’re iterative, living documents that can help you visualize assumptions and relationships between capabilities and business goals. Whenever you deliver something into production, you should be able to validate certain assumptions, and you may prove others wrong. Based on this feedback, you’ll be able to update your impact map and your short-term plans accordingly.

Exercise 3.5

Flying High Airlines partners with the major credit card providers. They issue credit cards that members can use to accumulate Frequent Flyer points when they make ordinary day-to-day purchases. Flying High Airlines receives commissions when Frequent Flyer members purchase goods this way. Identify the underlying business goal behind this strategy, and draw up an impact map to discover how the Frequent Flyer website might contribute to this goal.

Impact Mapping is a simple and convenient approach to building up an initial picture of what you’re trying to achieve in a project. Impact maps are visual and intuitive, fast to draw, and accessible for both business people and technical folk.

Impact maps can also be used quite effectively in the other direction, though for a slightly different purpose. Suppose, for example, that you already have a set of proposed features: a product backlog in an Agile project, a set of use cases, or even a set of high-level requirements in a more traditional requirements-specification document. Suppose, while you’re at it, that the requested features come from different stakeholders, who are each convinced that “their” feature should be done first.

In this case, impact maps make a great conversation starter. I’ve found the following strategy effective: get your stakeholders together, put the requested features on a whiteboard, and identify who they’ll benefit and how they’ll benefit them, working back to the underlying business goals. Eventually you’ll end up with a graph that shows a number of goals, with a relatively clear illustration of which features map to which goals. This visual representation of all of the goals and the supporting features is an excellent starting point for a discussion of the relative merit of each goal, and of each feature, and makes it much easier to prioritize the different features more objectively.

If you’re interested in learning more about Impact Mapping, take a look at the Impact Mapping website (http://impactmapping.org) and read the book Impact Mapping by Gojko Adzic.

3.6. Who will benefit? Identify stakeholders and their needs

As you’ve seen, all projects ultimately aim to benefit the organization in some way. But organizations are made up of people, and it will be people within this organization (or people who interact with this organization) who will be affected by the outcomes of your project. These people are the stakeholders or actors. The impact maps we looked at earlier emphasize the importance of stakeholders in identifying valuable features. Let’s look at this in more detail.

Note that even when the overall effect of a project is designed to be beneficial for the organization, the impact of the project on an individual basis may be negative. For example, adding additional steps in a mortgage application process may be perceived as being cumbersome and annoying for the banker selling the mortgage and for the client applying for a house loan. But the net effect of reducing the risk of bad loans may be considered beneficial enough for the bank as a whole to outweigh these disadvantages. It’s important to be aware of these negative impacts, and to try to minimize them where possible.

Many different types of stakeholders will be interested in the outcomes of your work. Future users of your product are probably the most obvious example; their daily work will be impacted by your project, for better or for worse. For the Frequent Flyer website, this category of stakeholder will include current and future Frequent Flyer members. It may also include call center staff, who will have to answer questions from Frequent Flyer members about the new program and be able to view a client’s current status and miles. They may also need to perform more complicated tasks that are not yet supported on the Frequent Flyer website, such as transferring Frequent Flyer miles between family members or crediting earned miles manually.

Note that future users may not always be directly interested in the business goals. A Frequent Flyer member has no particular reason to want to see an increase in Flying High ticket sales. Sometimes what the user wants and asks for will have little or no bearing on the original business objectives. When you think about what features you need to deliver to achieve the business goals, you need to think in terms of how you can encourage these stakeholders to behave in a way that helps you achieve the goals. For example, you’ll want to provide features that encourage users to book flights with Flying High rather than with a competitor in order to increase ticket sales revenue.

Another category of stakeholder includes people who won’t be using the application themselves, but who are directly affected by, or interested in, the outcomes of the project. For example, Bill is the Director of Sales at Flying High Airlines and is therefore responsible for ticket sales. An increase in ticket sales revenue of 5% will help him meet his own goals of increasing sales revenue in general. In addition, his budget is paying for the new Frequent Flyer members’ website, so understanding and quantifying this business goal will give Bill a way to justify the cost of the project in terms of ROI (return on investment). With this information, Bill can see how much the project is likely to earn in increased revenue, and therefore have a clearer idea of how much he’s willing to spend to achieve these increased earnings.

Other stakeholders will not be directly affected by the project, but will want to have a say in how the project is implemented, and may have the power to block the project if they aren’t contented. Regulators, security folk, and system administrators are good examples of this sort of role.

The actual role of the various stakeholders in achieving business goals and delivering business value is often overlooked. If users don’t use the application in the expected way, the software may not realize the benefits you expected. Looking at things from another angle, a very effective way to identify the features that are most likely to support the business goals and provide real value is to think in terms of changing stakeholder behavior. How can you encourage users to behave in a way that supports the business goals?

Once you’ve identified the principal stakeholders and understood their goals, you can think about the capabilities that you need to provide to meet these goals.

3.7. What do you need to build? Identify capabilities

A capability is the ability of your application to help stakeholders realize a business goal. Capabilities are high-level concepts that don’t commit to a particular implementation. Because they’re implementation-neutral, they give you a lot of flexibility as to how you build the underlying features.

I was once called in to help out a software development shop that specialized in the real estate market. They were trying to build a new application to help real estate agents provide property management services for property owners.

One of the aims of the application was to compete with and beat an existing rival product that already had a good hold on the market. After reading the competition’s user’s manual, the business owner listed the requirements that he wanted us to implement. It went along the following lines:

· Add a new property owner

· Archive a property owner

· Delete a property owner

· Send notifications to property owners

· ...

These requirements were quite possibly necessary for the application to work correctly, but it was less clear precisely what role they played in meeting the application’s business goals. Remember, every feature a developer builds needs to be delivering value to the organization in some way (see figure 3.9). For example, why did they need to add a new property owner? How many new property owners would be added per month? Is this likely to change over time, and, if so, how quickly? Viable implementations of this capability could range from a manual SQL insert performed by a system administrator to a fully automated web interface where property owners sign up and create their own accounts with no manual intervention. Until the business goals were clearly defined, they had no way of knowing. These requirements were also quite low-level, and gave no context or background as to why they might want to add a new property manager or send property owners notifications, for example.

Figure 3.9. The ultimate purpose of any new feature is to deliver value to the organization. If it’s not doing this in some way, it is probably waste.

As we discussed earlier, this “shopping-list” style of requirements doesn’t lend itself well to understanding why a particular feature is needed and makes it hard to adapt to change when your understanding of the true business needs evolves, when new requirements emerge, or when technical or nontechnical issues force you to change your tack.

To rectify this, the real estate development team tried to determine what it was that the application was trying to achieve. After popping the why stack a few times, they managed to identify the following core business goal:

Goal: Win more management contracts by providing better service to property

owners

In order to win more management contracts

As a property manager

I want to be able to provide better service to property owners

Supporting this goal, they came up with a set of high-level capabilities that included the following:

Capability: Notify the property owner at promised times

In order to provide property owner-specific notification schedules

As a property manager

I want the property owner to be able to set their preferred notification

schedule

Capability: To have peace of mind regarding managed properties

In order to provide property owners easy access to their statements

As a property owner

I want to be able to access vital statistics about my managed properties at

any time

Capability: To ensure that I pay the promised recurring expenses

In order to manage recurring expenses

As a property manager

I want the payments to be done automatically or be reminded about them if I

need to intervene

Not all capabilities are focused on business functionality. Some, such as security and performance, can apply across the whole system. For example, they were able to define the following security capability:

Capability: To keep confidential information safe

In order to ensure that my customer information is only available to my

employees

As a property manager

I want client data to be only transmitted over a secured connection

In another situation, they needed to be able to deliver reliable service to property managers in rural areas, where internet connections are notoriously slow:

Capability: To provide a viable service in rural areas

In order to benefit from the service when working in remote rural areas

As a property manager

I want to be able to still use the essential features of the system

effectively over a slow internet connection

From here on in, they were able to start having conversations about features that they could build to deliver these capabilities: what sort of statistics would a property owner need to see, what would it look like on the screen, what would the user experience be like for the property owner, and so on.

Features are the implemented components in an application that deliver a capability to the users. For example, several different features might have helped the development team deliver the “provide property owners easy access to their statements” capability mentioned previously, such as a property dashboard page on the client website or an iPhone property-management dashboard app. We’ll discuss the concept of features in much more detail in the next chapter.

Impact maps, as you saw earlier, can help you explore these ideas at a higher level, before discussing each capability or feature in more detail (see figure 3.10).

Figure 3.10. Impact maps are a good way to explore goals, capabilities, and features at a high level.

3.8. What features will provide the most ROI? The Purpose-Based Alignment Model

Feature Injection can help you decide what features you really must have in order to deliver the business value you need to deliver. But there’s another dimension that’s also worth considering. Not all features are equal. Some features will be areas of innovation, requiring specialized domain knowledge and expertise and adding significant value. Others, such as online payment with credit cards, might be necessary in a market, but won’t distinguish your product from the competition in a meaningful way. Knowing where to invest your time and effort is essential in ensuring that your product not only provides value, but also provides high return on investment.

One convenient way to measure this is to use the Purpose-Based Alignment Model, invented by Niel Nickolaisen.[7] Using the Purpose-Based Alignment Model, you classify features into four quadrants of a diagram, like the one in figure 3.11, using two simple criteria:

7 Pollyanna Pixton, Niel Nickolaisen, Todd Little, and Kent McDonald, Stand Back and Deliver: Accelerating Business Agility (Addison-Wesley Professional, 2009).

Figure 3.11. The Purpose-Based Alignment Model helps identify where you should focus your efforts when building features.

· Mission critical —How essential is the feature for your ability to operate as a business?

· Market differentiation —Is it significantly different from what your competitors propose? Will it make you stand out in the marketplace?

Depending on where a feature is positioned in this diagram, you can decide how best to focus your efforts on those features that will make a difference. A feature will fall into one of four categories:

· Differentiating

· Parity

· Partner

· Minimum impact

3.8.1. Differentiating features

A differentiating feature is both mission critical and marks your product apart from the competition. These are the features that provide high return on investment or that win market share, or both. They give your organization a competitive edge. An example might be a risk analysis tool for an investment bank or an innovative new way to reconcile bank account statements in an online accounting package.

These features typically rely on specialized domain knowledge and skills, so it makes sense to build them with in-house resources. Features in this category need to be highly innovative in order to gain and maintain a competitive advantage.

3.8.2. Parity features

A parity feature is mission critical but doesn’t provide much market differentiation. These are features that aren’t particularly glamorous but are required for the product to be viable. All your competitors provide these features, and it’s expected that you do too. An example of a parity feature might be online payment with credit cards for an e-commerce site, or the ability to view old account statements for an online retail bank.

As the name suggests, you need to implement these features to provide roughly the same level of service as is found in competing products. If you do any less than that, you’ll put your organization at a competitive disadvantage. But it would be wasteful to spend too much effort on these features, as the return on investment will be marginal.

3.8.3. Partner features

Partner features are not mission critical but can still differentiate your product from the competition. These features are not usually part of the core expertise of your organization, so it might be inefficient to build up this expertise for one project. In this case, it makes sense to team up with a partner who is more specialized in this area.

3.8.4. Minimum impact

Some features are neither mission critical nor market differentiating. You should try to spend as little time and effort as possible on features in this category. These low-value features might be a good candidate for outsourcing.

3.9. Summary

In this chapter we discussed Feature Injection and various related concepts. You learned about the following:

· Identifying and understanding the fundamental business goals behind the applications you build makes it much easier to design and build valuable features.

· Feature Injection is a technique that tries to identify the business value that an application is expected to deliver, and to identify the essential features that will deliver this value.

· Impact Mapping enables you to visualize the relationships between stakeholders, capabilities, features, and business goals.

· The Purpose-Based Alignment Model helps you decide how much effort to put into the different features you decide to implement.

In the next chapter, we’ll take these ideas further and look at how you can discover the features and scenarios most likely to deliver value. We’ll also look at how you can better manage your lack of knowledge, and understand and prioritize the features you build and deliver, using concepts such as Deliberate Discovery and Real Options.