This article builds on two preceding articles that you might (or might not) want to read before you read this one. These articles' names are Can agile software development support Business Agility? and Sustainable Software to Business Alignment. (You may also read them after having read this one.)

Martin Fowler told us to organize our microservices around business capability. Many others have repeated the same advice. But what does it mean? What is a business capability? Where do we find them. The answer is simple! They're rignt in your team's product backlog! Learn more about it here.

How do Product Backlog Items relate to Business Capabilities?

The question is relevant for software development, at least if you take Martin Fowler on his words. In his and James Lewis's pioneering article on Microservices they firmly state this: "Microservices should be organized around business capabilities."

So what is a business capability? And what is a capability model?

About Business Capabilities

Australian Glenn Smyth is the founder and CEO of Fragile to Agile, a concultancy defined by the keywords Agility by Design. In a YouTube video he explains it in simple terms:

"A business capability model is a model of what an enterprise does. It deliberately ignores the how it does it and who does it, because those two things are far too changeable. In contrast, what an organization does is quite stable over time."

He then adds that this stability makes business capabilities incredibly useful for overlaying technology changes over time

He's rightly corrected by a commentator that says that it's not a model of what an organization does. It's a model of the capabilities it requires for doing certain things.

Product Backlog Items vs. Business Capabilities

And that is exactly what most Product Backlog Work Items are. They are statements about what capabilities the organization requires for doing what it must be able to do. Consider this common example of a user story:

As a sales assistant, I want to fetch data on a customer, so I can register a sales opportunity about that customer.

You can't fetch data on a customer unless you have a capability for doing it. Everything someone in an organization needs to do requires a capability for doing it. Being able to fetch data on a customer represents a business capability, even if that capability is on the lowest level possible. It's still a business capability. As well as it is a user story.

Features and Epics

The business purpose of this user story is to register a sales opportunity. The user story sentence says exactly that: "... so I can register a sales opportunity ..." When the sales opportunity is registered, a piece of business value has been created. Fetching data on a customer cannot by itself create that business value. It can, though, be one of the steps needed for doing it.

One of the characteristics of a feature is that it creates real business value. This is exactly what the registration of a sales opportunity does. That's why it should be classified as a feature or an epic. Another attribute of a feature is that it's typically completed in the same "sitting" as it started in. The sales assistant could describe it as follows:

As a sales assistant, I want to register a sales opportunity, so that it becomes available for sales activities.

The typical behavior of the sales assistant would be to sit down, start the registration of a sales opportunity, and keeping with it until it's on file. All in one sitting. That's why it's a feature and not an epic. A good name for it would be Sales Opportunity Registration.

That feature could be grouped together with other features, all concerning the management of sales opportunities. Sales Opportunity Management would be a perfect name for that. It would be an always ongoing activity, so in the Product Backlog it would be an epic. Its sentence could be something like this: As a sales manager, I want to manage sales opportunities, so I can reach my sales goals.

The same repository - two different views

Consider the opportunities this gives you. Structuring your Product Backlog as business capabilities would enormously improve your discussions with business managers and their staff. You would get much better business feedback, and you would be in a much better position for building the right system for them. With fewer retakes than is common, which means faster delivery, less work, and a lower cost of development.

Putting it all together, we would now like to show you a picture. It shows two versions of the same set of backlog items. The leftmost version is the common version that Azure DevOps Services displays. The rightmost version is a business-flavored view of the same set of backlog items. A business capability view, if you like to see it that way.

Both come from the same product backlog store. Changes made in one of the views immediately affect the other view.

The business-flavored view relates better to business stakeholders, because it's looking more like the picture they normally use. This makes it easier for them to recognize their business activities. This in turn makes it easier for them to spot errors and misunderstandings and give you extremely useful business feedback. Which again gives you a chance to deliver faster, more correctly, and at a lower cost.

That impression grows when you start climbing up and down in your hierarchy of user stories, features and epics. The developer view isn't made for that, which the business view is. Guess which one would give you the best result from a meeting with business stakeholders!