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.
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.
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.
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.
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]
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.
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.
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.
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.
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 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.
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.
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?
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.
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.
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:
In this chapter we discussed Feature Injection and various related concepts. You learned about the following:
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.