What Is and What Is to Be: Minimum Business Increments and Stories

January 13, 2017 — Posted by Ken Pugh

When looking at changes to be made to a system, one can look from the system's perspective (what changes need to be made) or one can look from the workflow perspective (how the bundles of changes to be made). Both views are important. One shows what is “to-be”; the other shows how you are going to get there.

Change in System

Here’s an example showing where in a system a change is being made. From the existing “As Is” capabilities, this shows there are going to be changes in one sub-feature under Feature A and in a new Feature B. You may have a different way of expressing your system hierarchy.

Workflow of Change

The other way of showing the change is by the change itself. Changes can be part of a series of changes, often called an epic. One or more changes are bundled into a minimum business increment (MBI) – the smallest set of changes that delivers business value and is separately releasable. An MBI can contain a composition of features on many levels (e.g. features, sub-features, sub-sub-features, etc.). Stories – independently developable changes that are typically grouped by the feature in which they are organized in the system.

Let’s take a little more detailed look these pieces:

Minimum Business Increment

An MBI represents the minimum amount of change that provides business value. It may contain a single story, but it often has one or more features or containers of stories. It usually encompasses a single business capability, but it could be cross-capability such as making all drop-down boxes consistent across an application. An MBI should be releasable by itself. If MBIs have dependencies, then they should be sequenced for development so the dependent MBI is after the MBI it is dependent upon. An MBI has business value determined by the business. MBIs can have business tests for that value.

An MBI may be created by synthesis – combining multiple changes into a single one or by differentiation – splitting a change into features or stories.

Feature

A feature can contain multiple stories or multiple sub-features. The term feature has many connotations, but here it’s being used in the container sense. Features typically do not have acceptance tests (absolute pass/fail tests) associated with them, but they can have acceptance criteria (a general expression of success). They have business value in the sense that they are part of an MBI which has business value. However, that business value is not achieved until the MBI is released.

Story

A story is a change that is independently developable, usually by a single team. It has one or more customer/user acceptance tests that help define the details in the story and provide a pass/fail check on the implementation.

Implementing a story may require assistance from other teams. Typically, technical stories (also called developer, implementation, or enabling stories) are created for those teams. Technical acceptance tests are produced for those stories.

Since the business value of an MBI is not achieved until all stories within it are implemented, the stories can be developed in whatever sequence makes sense from efficiency and need for feedback.

A Few More Aspects

Here are a couple of more aspects on changes – impact mapping, story mapping, and minimum technical increments (MTI).

Impact Mapping

Changes to a software system are often the effect and sometime the cause of a change in a business workflow or other business relationships outside of the application development group. For example, a change in a website may cause more customer service calls (or hopefully fewer).

The impact of the change should be mapped (See www.impactmapping.org for one approach). The chart below gives a view of how to document the impacts for an MBI.

Before a change is deployed, consideration should be given to these impacts to ensure that they are dealt with taken. Impact planning should start when the decision is made to develop a particular MBI.

Story Mapping

Another way of looking at MBIs is to show them in relationship to a story map (see www.agilealliance.org/glossary/storymap/)

In one form, the steps in a workflow are represented by stories. If a step has alternatives, then related stories are shown in line with that step. For the initial MBI, at least one story from each step must be implemented so that the workflow can be accomplished. Subsequent MBIs can involves a selection of related stories. There does not have to be one from each step.

Minimum Technical Increment

There are technical changes to an application or a system that are made for a more general purpose than supporting an individual MBI. Example, changing to a new version of a database usually affects many applications. Technical changes affect the technical capabilities of a system. Some of these capabilities revolve around cross-functional issues such as maintainability and performance. Some people call technical issues enablers since they enable the business capability to be delivered.

These technical changes can be organized in a manner parallel to business capabilities. For example, technical epics, minimum technical increments, technical features, and technical stories.

Minimum technical increments (MTI) represent the minimum amount of change that provides technical value. It may contain a single technical story, but it often has one or more features or containers of stories. An MTI should be releasable by itself. It’s difficult to prioritize MTI and MBI together, since they have different types of value. Instead, a percentage of capacity is often reserved to implement MTIs.

A technical story a change that is independently developable, usually by a single team. It has one or more technical tests that help define the details in the story and provide a pass/fail check on the implementation.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Ken Pugh

Ken Pugh was a fellow consultant with Net Objectives (www.netobjectives.com). He helps companies transform into lean-agility through training and coaching. His particular interests are in communication (particularly effectively communicating requirements), delivering business value, and using lean principles to deliver high quality quickly.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban