How to Map Agile with Business Capability

The value of capability mapping is to provide the useful tool to align products with business vision, or at higher level, to visualize the enterprise.
The vision of the company direction, and therefore the direction of the different products, services, the functionality of business processes, and ability of people etc. is generally expressed as business capabilities. Portfolio decisions should be made in the context of those capabilities. Epics, stories, features should all trace to the business capabilities. This not only gives you a better view of how and what you're doing to build out the system, it also allows you to better communicate on a regular basis of the benefits, the level of maturity, and other aspects of the system to those who care.


The asset stewardship is the ongoing work of the business to describe the vision and direction of products: The exact business capability needed and where in the business process should it reside, then drives the application; this capability should be put in and ultimately the technical architecture that drives its implementation. The business side is independent of a particular project or work effort, think of that as Asset Stewardship, and it is the ongoing work of the business to describe the vision and direction of a product, service offering, capital asset, etc. within the overall vision of the company. This is not what Agile thinks of as Product Owner. It is also not Portfolio Management. Asset Stewardship is considering the needs of today in the context of a 3-5 year vision that is not locked in stone but that does provide a direction.

Use the Objective/Key Results format for business capability mapping. Show how implemented features relate to business goals. Investment themes are used to categorize development by internal investment types. Use these to answer questions such as: How much effort did you spend this year on development for existing customers vs new market growth vs sustaining. The objective describes the business level problem you are trying to solve. For example: “Reduce cycle time for workflow X in order to increase revenue per seat.” The key results describe expected business results that will be delivered and when. For example: “Increase revenue per seat by 10% by EOY.”

You can also create data flow diagrams showing business goals, expressed as high level processes; and then, to the degree, if detail necessary, decompose these business goals into subgoals, and then into supporting processes or projects. The good mapping mechanism allows you to create a capability model or some backlog of capabilities that you can then tie to specific features or even better, to the story level. This way, as you deliver stories, functionality, features, you can tie them directly back to the specific capabilities that are cared about by your customers (external or internal). Sometimes (depending on size), use Epics (WHY) -> Story (WHAT) -> Subtasks (HOW) where an Epic unifies all work needed for a singular business outcome and the collection of business outcomes within a release to denote the capability being built. - release notification notes specifying impact on the value streams/business areas
- motivation to understand the business, so you can speak the same language- there is incremental log of functionality mapped to the version and existing business process.

Therefore, the value of capability mapping is to provide the useful tool to align products with business vision, or at higher level, to visualize the enterprise. It allows business leaders or Agile managers to establish important business goals or products/projects initiatives relevant to the capability and identify goal dependencies to both doing the right things and doing things right, and ultimately establish a high mature enterprise.
Follow us at: @Pearl_Zhu