Requirements Tree

I often recommend that a company or product team understand their requirements lineage, which I term a requirements tree. It is a structure that represents the relative hierarchy among various requirements elements within your enterprise. The idea that has been discussed in previous chapters is a key requirements element that is at the larger end of the requirements element spectrum. User stories are found at the smaller end of the requirements element spectrum. Since requirements drive the work within an enterprise, it is good to know if you are working on the highest-value requirements or random requirements that made their way in through the secret and often unevaluated backdoor. Can you trace the lineage of user stories and tasks to the high value idea they represent?

What are the various requirements elements? There is no industry standard group of requirements elements, and they can vary from enterprise to enterprise. The point is to understand what yours might look like. I like to start with corporate strategy and end with tasks, as illustrated in Figure 15-1.

Figure 15-1. Example of a requirements tree

Once you establish the levels of your requirements tree, it is important to craft a definition to describe each level. Using the requirements levels from Figure 15-1, here is how I describe each level. A corporate strategy includes high-level goals and direction set for the enterprise. A division strategy focuses on goals and direction for a division. An idea is a value-driven and outcome-based opportunity. An increment is an end-to-end slice of the idea to validate the value of an idea. An epic is a function, feature, or large user story. A user story is a requirement that fits into a sprint or can be completed in days, is non-compound, and is for one persona. A task is a very small unit of work that has a tangible result of incrementally building the user story.

You may notice that instead of putting the corporate strategy on top, I place it on the bottom. I do this to represent the corporate strategy as the trunk of the tree because it should provide guidance for how the smaller requirements elements (such as ideas, increments, epics, user stories, and tasks) should grow. While your strategy may adapt over time based on customer feedback and where your market place is headed, it should guide the type of work you may consider in the short run.

This version of the requirements tree as illustrated in 15-1:

Corporate strategy to division strategy to ideas to increments to epics to user stories to tasks

Other versions of a requirements tree may be as follows:

Business vision to business objectives to business requirements to technical requirements to tasks

Corporate objectives to features to use cases to user requirements to tasks

The key to your requirements tree is for you to establish one that makes sense for the type of work you do. For example, if you only have one division in your company, a division strategy isn’t necessary. Those that may consider creating a requirements tree are a combination of executives, product owners, and team members. Once crafted, the tree should be shared with everyone.

Attributes of Requirements Elements

Having a requirements tree benefits you in several ways. First, the tree helps you understand the relationships of the various requirements elements from the largest requirement (corporate strategy) to the smallest requirement (task). Second, the tree helps management and employees understand what level of requirement is being discussed. Third, it helps you understand if you are missing a requirements level. While it can be reasonable to miss a level, you should be aware of it to determine if a discussion is necessary.

As you think about the ideas that flow through your organization and how to decompose them into user stories and tasks, it is important to know what your requirements tree might look like and the attributes the requirements elements should have. This may include the following:

• All requirements elements should be customer-value focused.

• Other than corporate strategy, all other requirements elements should have a parent (the epic is the parent of the user story) unless unneeded (some user stories won’t have tasks).

• For every parent, there are typically two or more children requirements elements (an idea is made up of six epics).

• Not all children need to be completed in order for the parent requirements element to satisfy the customer need (five of the eight user stories of the epic may satisfy the customer).

Within an enterprise, different divisions, groups, and teams can have different requirements trees. The exception is that the more dependencies and collaboration among teams, groups, and divisions, the more mutually beneficial it is to have a shared and common requirements tree.

Navigating the Requirements Tree

There are at least three key benefits to having a requirements tree. First, it can help you understand the level of the requirement being discussed. This may be more important than initially realized. If someone is talking about a requirement at the user-story level vs. the idea level, the discussion can derail very quickly. At the idea level, it may be more of a divergent conversation where people are considering options, while, at the user story level, it may be more of a convergent discussion where people are attempting to pin down details because it will be worked on very soon.

Second, a requirements tree can help you understand if tasks, user stories, and epics are traceable to an idea. Understanding the traceability of work can help you know if the work that is considered of customer value is indeed being worked on. It can also help you ascertain if some user stories are getting inserted through the backdoor from another source, instead of coming from the idea. This can explain why key user stories are not getting completed. It is reasonable to have requirements come from other places, but there should be accountable awareness that it is occurring.

Third, having a requirements tree can help you educate the team, management, and particularly new staff on the levels of requirement types, who participates at each level, and what Agile concepts and practices may be used at each level. Figure 15-2 illustrates an example of the requirements tree in action and how you might decompose from the corporate strategy level up to the task level.

Figure 15-2. Working example of navigating the requirements tree

In this example, I start with the corporate strategy, which may be to satisfy banking customers with innovated products. From there, a division strategy will consider the corporate strategy and apply it to provide banking customers with mobile applications. Then an idea may be to build a mobile app that will increase sales by 30% for mobile users in the next three months.

An increment of the idea may be a thin slice to build a secure login to a customer’s account and query bank balance. From there, epics may be to create login, validate customer credentials, and query bank balance. Using the query bank balance epic, a user story may be as follows: As David the Gen X-er, I want to view my savings account balance, so I know how much money I currently have. Tasks could be to create mobile display frame, create link to savings database, and add saving account balance.

Aligning Roles to Tree

A benefit of having a requirements tree is that you can consider who might participate at each requirements level, as illustrated in Figure 15-3. While it is reasonable for everyone in an enterprise to have input into a requirement at any level, there is typically a bounded authority as to who has the responsibility at each level. Of course, all requirements should be driven by the focus of delivering customer value and not arrogant certainty, so expect changes to requirement to occur as customer feedback is received.

Figure 15-3. Role alignment to requirements tree

For example, who has the bounded authority over the strategy, who has the authority over an increment of an idea, and who has the authority over the user stories? For a corporate strategy, senior management may make the decision to consider top strategies. For considering increments of an idea, the product owner may make the decision but include input from the team and customers. At the user-story level, the team makes the decision on how to craft and self-organize around them.

How might your roles align with your requirements tree? Keep in mind that anyone can contribute an idea, but only the senior management or product owners can make the priority call.

Aligning Agile to Tree

Another benefit of having a requirements tree is that you can consider what Agile concepts and practices may be suited at each requirements level, as illustrated in Figure 15-4. While it is reasonable to experiment with many of the Agile concepts and practices that may work at various requirements levels, it can be beneficial to have a starter set and then adapt as you learn what works well or what the feasible options are. For example, it may be reasonable to start with use cases to help you cut increments and then advance to story mapping once there is experience with it.

Figure 15-4. Example of Agile concepts and practices used at each requirements level

Following Figure 15-4, executives may use a vision statement to share goals with the company at an all-hands. The divisions use a Business Model Canvas to discuss where they’ve been, where they plan to go, and how they plan to support the vision. Ideas come through the enterprise idea pipeline via a Customer Value Canvas that include a cost of delay (CoD) and value score.

To understand if the idea has value, the idea is decomposed using story mapping and an end-to-end, thin slice of the idea carved out. Epics and user stories that come from the increment are added to the backlog and groomed. Use cases are used to flesh out the epics. User stories are written in canonical form and have a corresponding unit test. Tasks are then written following an incremental development mindset to incrementally build the user story.

As part of the Agile concepts and practices, feedback loops discussed in Chapter 14 should be considered for each requirements level to validate the direction toward customer value. Find the Agile concepts and practices to help you decompose the work from strategy to task that work best for you.

What Does Your Requirements Tree Look Like?

The term requirement can be quite nebulous as it can mean requirements at many different levels. Do you mean corporate strategy, user story, feature, idea, or something else? I suggest that you do not assume everyone understands the requirements levels in your enterprise or product team. Instead, establish a common requirements tree so people have a baseline of common terms. This doesn’t mean the terms and levels are locked in, but instead they will be something you mature and adapt over time. A requirements tree provides lineage from user stories and tasks to ensure that high value ideas are being worked on.

I have found that it can be beneficial to create a requirements tree diagram that includes all three aspects (requirements elements example, roles, and Agile concepts and practices). This can be an effective one-pager similar to a canvas to provide both transparency and guidance on how requirements are related and how people work together in the enterprise to create customer value.