Agile Requirements Structures, Part 1

If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them.

There are many causes for this confusion. Here are some of the more common I have seen:

• Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation.
• The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it.
• The organization has not documented its own requirements model very well.
• The organization mixes two or more different requirements models, often without realizing it.
• The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when Henry Stanley found David Livingstone.
• The organization uses tools that locks it into a requirements model that is a poor match with the organization’s needs. Jira and Azure are the two worst offenders I know of.
• The original requirements model the organization based its own requirements model on is confusing, and may have omissions, or outright bugs. (Looking at you, SAFe!)
• Some combination of the above.

Agile has two common types of requirements models, User Story based models, and Use Case based models. In this article, I’ll write about User Story based requirements models. The two models can be mixed, sort of, but one needs to understand them both, or confusion will ensue.

I won’t go into detail about each type of requirement. Rather, I’ll focus on the overall structure. I will provide links, mostly to the SAFe website, to pages where you can read more about each type of requirement.

I’ll start by deconstructing the SAFe requirements model. This model can be quite confusing, but we will untangle it step by step, make a few adaptations, and come up with a model that is both understandable and useful. This model probably will not fit your organization as-is, but it can provide a base structure that is easier to adapt than the SAFe model, or the requirements-from-hell models in Azure and Jira.

I’ll write in more detail about the various types of requirements in a future blog post.

Untangling the SAFe requirements model

Prepare to be confused! Here is the SAFe requirements model, as it is presented on the SAFe website:

If you find the above model easy to understand, you are way smarter than me. I need to untangle it, step by step, to understand what’s going on.

First of all, this diagram is a re-purposed UML (Universal Modeling Language) Class Diagram. A Class Diagram is intended to show the relationships between classes when doing Object Oriented program design. It is good at modeling classes and subclasses, and realizations, where one object specifies behavior and another object executes it. Class Diagrams suck at modeling information hierarchies, which is what a requirements model is.

Using this kind of diagram causes a mismatch between what we try to describe, and the way we describe it. In the world of information modeling, this is called an impedance mismatch.

The diagram above uses the phrase “realized by” to describe levels in the requirements hierarchy, which makes the whole thing difficult to understand, especially for business people. An additional problem is that the diagram describes too many things at once.

Let’s simplify a bit, and focus on the requirements hierarchy:

Drawn this way, using a hierarchical diagram, the SAFe structure still looks like an overcomplicated mess. It has one advantage though: We can begin figuring out what’s wrong with it!

Taking it from the top, we have six different top entities in the structure. This is weird, because as in Highlander, there can be only one. Well, at least, we would expect there to be only one. We certainly would not expect it to be more different types of entities at the top than at the bottom.

Let’s have a closer look!

Look at the three types of Business Epic: Portfolio, Solution Train, and ART.

Without going into details, in SAFe, a SAFe portfolio is

“…a set of value streams that delivers a continuous flow of valuable solutions to customers within a common funding and governance model.”

For example, a portfolio could be a group of products. I emphasized a few words in the quote above, because they are important, as we will see.

A Solution Train is:

“…the organizational construct used to build large solutions that requires the coordination of multiple ARTs and suppliers.”

Putting these two quotes together, it is pretty obvious that a portfolio is higher in the organizational hierarchy than a Solution Train. This implies that a Portfolio Business Epic should be higher in the information hierarchy than a Solution Train Business Epic.

And yet, according to the SAFe Requirements Model diagram, they are on the same level. This looks suspiciously like an error in the original diagram.

Before we draw conclusions, let’s look at the ART Business Epic:

ART is an acronym that stands for Agile Release Train. An Agile Release Train is:

“…a long-lived team of Agile teams that incrementally develops, delivers, and often operates one or more solutions in a value stream.”

It seems clear from the descriptions that, since a Solution Train coordinates several ARTs, and it is the ARTs that develops and delivers the solutions, a Business Solution Epic should be at a higher hierarchical level than a Business ART Epic.

Thus we can form a hypothesis: The hierarchical order of Business Epics, from the top and down is: Portfolio Business Epic, Solution Train Business Epic, and last and least, ART Business Epic.

If we check SAFe’s Epic page, we find that it is mostly about Portfolio Epics. There is one interesting paragraph:

There are two types of epics, each of which may occur at different levels of the Framework. Business epics directly deliver business value, while enabler epics advance the Architectural Runway to support upcoming business or technical needs.

This confirms that there are Epics that “may occur at different levels”. In other words, there is a hierarchy of Epics. This directly contradicts the structure in the diagram of the requirements model, but it is consistent with the naming of the Epics in the same diagram. The quote does not say explicitly what the hierarchy is, but the order we hypothesized seems reasonable, so we will go with that.

If we ignore the Enabler type entities for the moment, we can see in the original UML diagram that Business Capabilities are above Business Features, and Business Features are above User Stories.

We now have:

We can tie this together, because the UML diagram says Epics are realized by Capabilities, which means all Epics are above Capabilities in the hierarchy.

We get:

Note that Business Capability is an optional entity, so in the original UML diagram, any kind of Epic can contain a mix of Business Capabilities and Business Features. We will deal with that later. For now, we will assume Business Capabilities are always there.

What about Enablers?

According to the SAFe Enabler page, Enablers are:

“…backlog items that extend the architectural runway of the solution under development or improve the performance of the development value stream.”

To decode that, we need to know what an architectural runway is:

“The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features with minimal redesign and delay.”

So, an Enabler is a requirement to build a piece of technical infrastructure, or component, or a major refactoring needed to improve performance, or simplify a design.

In other words, an Enabler is a task. Depending on the type of Enabler, it can be anything from a relatively small task, to a really, really big task.

If we look at Enablers only, we can see in the original UML diagram that Enablers are structured exactly the same way as business requirements. The structures are intertwined, but we will start by looking at them separately:

To me, it is weird that an enabler can be at the top of the requirements hierarchy. An Enabler should always enable something on the business side. If you do not have that connection, it is easy to build a system with a lot of Enablers that serve no business purpose. This can happen in functionally organized organizations, where architects and the business side live in functional silos, with little contact with each other.

It would be nice if we could see in the structure that an Enabler enables something with business value. Technically, we could do this with lateral links, for example, a link between Portfolio Business Epic and Portfolio enabler Epic. I would prefer to do without lateral links unless absolutely necessary, so let’s try it by modifying the hierarchy first:

This looks a little bit better, because now, Enablers are always tied to business value. The names look a bit weird. For example, it would make sense if a Portfolio Enabler Epic was named Portfolio Epic Enabler, because it is an Enabler that enables a Portfolio Epic.

Let’s try it out:

In every organization I have worked with, people omit the word “business” when referring to business requirements. I’ll do the same, because the word “Enabler” still distinguishes the Enablers. I’ll also add Task as a sub-level to User Story, just so you won’t wonder why it isn’t there:

This structure is, I believe, a little bit easier to understand and customize.

What’s the difference between a Task and a Story enabler? In this context, a Task must be executed to make one particular User Story work. A Story Enabler is a task that, when executed, enables more than one User Story. You may have noticed I am deviating a bit from the description of Enabler Stories in SAFe, but I do believe it is a deviation that makes sense.

It is worth noting that depending on the organization, and project or program you are working in, any business requirement from Portfolio Epic to User Story could be the top level of the hierarchy.

In a large company with portfolios of products, you will probably start at the Portfolio Epic level. For a small systems project, User Stories may be all you need. Anything in-between can be used as the top level, depending on your needs.

Just do not start with an Enabler. If you do that, the organizing principle is disrupted, you will start doing work items in the wrong order, and the whole idea of delivering business value quickly goes down the drain.

You may also wish to omit levels. In the SAFe requirements model, Business Capabilities and Enabler Capabilities are optional. You may wish to skip them too, or not. Depending on your organization, you might want to cut ART or Solution Train Epics.

If you cut out one or more levels on the business requirement side, it is probably a good idea to cut out the corresponding Enabler levels too. If you do not have Capabilities, you probably do not need Capability Enablers.

As I mentioned at the start, this is an experimental model. If you see any obvious flaws, please do comment. If you think it will hold up, let me know that too.

Be seeing you!