This is a chapter from Amplio Development: The Path to Effective Lean-Agile Teams

Often reducing batch size is all it takes to bring a process into control. Eli Goldratt.

There is nothing so useless as doing efficiently that which should not be done at all. Peter Drucker

  1. Work on small, releasable items
  2. Build in small, vertical slices
  3. Have definition of ready (DoR) and definition of done (DoD)
  4. Attend to the customer journey
  5. Agree on classes of service

Agile, Flow, Lean, and the Theory of Constraints all focus on the quick delivery of high-value items. As obvious as it is, it’s worth pointing out that smaller items are easier to get quicker. And smaller can provide feedback faster as well. This has been partially manifested with the concept of small stories that add incrementally to the value being built. But what must also be considered is that the ultimate focus must be on the value realized by the customer. We, therefore, need to consider two sides to the requirements.  First, what is the smallest releasable (realizable) value we have and how do we build it in small, end-to-end (in order to get feedback) slices.

The common artifacts of Agile – epics, features, and stories – do not provide what is needed. Epics contain much more than what is releasable. Features and stories are usually not of value to the customer on their own.

Of course, some things we build are big. We must attend to how can we release something sooner and how can we build that in stages if we need to.  We should first note that there are several different types of work. These include:

  • Creating a new product or service
  • Extending or enhancing an existing one
  • Maintaining existing systems

The time of creating and delivering value for the first two can vary considerably. In the first case, we’re more in a discovery mode of what the product should look like and if it is viable. This is often best done with minimum viable products (MVPs) and very short development – feedback cycles.

The second one is more of an investment in an existing product. In this case, we’re more likely to know what’s needed and it’s like that more supporting documentation and marketing are required. Here we want to deliver value quickly as well. We call this the minimum business increment.

While both will be built with small end-to-end cycles the context in which they are in is different. It’s worth keeping them separate as each will require different actions.

The main distinction between an MVP and an MBI is that an MVP is an investment in discovering if a product has value while an MBI is an investment in creating value. In all but very small companies there are other differences. MVPs are often able to be built by a small team. MBIs often need the coordination of several teams to create it. Hence, MBIs also include information about who is needed to create it. This enables coordination of the teams required and enables multiple team alignment.

MBIs can create a focus for Agile teams by making it clear that these are the items that are to be released. Most teams amass stories and features to be released but it’s better to focus on the actual value intended to deliver. This also enables culling out parts of a feature that aren’t needed for an MBI. The deferred analysis enables the team to release the MBI faster.

Why MBIs Are So Important

Consider these questions:

  • How are you deciding which market segment is most important to you?
  • How do you decide what it takes to deliver value?
  • How do you avoid working on
  • How do you align teams that are required to deliver value?

Notice how MBIs provide answers for these.

The capabilities for this section are:

2.1 Work on small, releasable items

2.2 Build in small, vertical, slices

2.3 Have definitions of ready (DoD) and definitions of don (DoD)

2.4 Attend to the customer journey while creating requirements

2.5 Agree on classes of service and their corresponding service level agreements

2.1 Capability: Work on small, releasable items


Let’s first consider the type of knowledge work being done, as that has a large impact on making these decisions. When:

  • doing new product development, MVPs should be used. This is also an indication to use flow as well.
  • enhancing an existing product, we should use minimum business increments (MBIs).
  • doing mostly maintenance work is done requirements are often minimal already and an equivalent to stories is good enough. This is an indicator for using flow unless there is a large backlog to choose from.

Why this is important

Working on small items enables quicker delivery of value. Working on large items is correlated with waste will slow feedback and delay the delivery of value.

High-value items can be used to align work to business value. If this is not present people will not coordinate what they are working on to get value out the door quickly.

Focusing on releasable items creates a bigger picture than just completing the story in front of a developer and facilitates cooperation.

How to implement with either timeboxing or flow

This is one of the key factors in deciding whether to use timeboxing or flow. If the product being built is not well-known, continuous demonstration, validation, and pivoting may be necessary. If we’re creating a new product with MVPs, then it is likely that flow should be used. When the speed of feedback needs to be high, recognize that planning an entire timebox will likely be a waste because we will change what we want to work on as we get feedback.

When using timeboxing work as closely with the customer as possible to get quick feedback. This will eliminate waste and improve product quality. However, the availability of the person who best knows what the customer needs is also a factor. If they are only available on an irregular basis, time-boxing may be the only option.

Organize the development intake around minimum viable products (MVPs) and minimum business increments (MBIs).

Make stories small.

Many teams that use timeboxing don’t do demonstrations of what they are building until the end of the iteration. So, if timeboxing is being used, try to get as much feedback from customers as you can.

Focus on completing stories, features, and releasable items as quickly as possible to provide feedback on the quality of what’s being built.

Get feedback after each item is accomplished.


Larger than necessary items cause delays, poor feedback, and too much work-in-process. When this happens, quality goes down and waste goes up.

<2.2 Capability: Build in small, vertical (end-to-end), slices.


Regardless of how big the item you’re working on you want to build it in small slices of functionality. This is so we can get feedback quickly both about whether we’re building the function that is desired and that the quality is high.

Why this is important

Much of the work we do is fixing problems due to a delay between making an error and detecting it. By having small stories/slices, we start and finish quickly.

How to implement when using either timeboxing or flow

Sometimes writing small stories can be difficult. One way to write them is to think of a single scenario and function relating to it. Then write the story to implement that. In some complex situations, you need to use Behavior Driven Development so you can use the construct Given-When-Then, but most of the time, writing small stories is not that difficult.


When large batches of work are planned or being worked on, feedback slows down, and people tend to work on more things simultaneously, causing both multi-tasking and delays. All of this causes even more work to be done, representing wasted effort.

2.3 Capability: Have definitions of ready (DoR) and definitions of done


Creating clarity on what is the highest value requires using a DoD.

DoRs and DoDs make explicit the agreements between people providing work to developers and developers saying the work is done. A DoR was sometimes used as a stage-gate in the past, so expect to hear some people say they are not a good idea. But in Amplio Development, we only mean them to be an explicit statement of the agreement between parties as to what it means for a work item to be ready. The DoR could be as simple as “it’s ready whenever the product owner thinks it’s ready.”  Most often, however, there are some other things the teams will want to see before working on it. This could be it has a DoD, been seen by marketing, a PO has seen it, or others.

A DoR is needed when handoffs are done, so each party understands their agreements with others.

A DoD is also an agreement between parties stating what it means for a work item to be considered to be completed. This may require specific actions while it is being worked on besides just what function the item is supposed to have.

Why This is important

Handoffs often cause loss of information or people not being adequately prepared to do the work being handed off to them. A DoR creates an agreement about what it takes to get something started. A DoD states what it takes for something to get done. DoD’s should include the functionality required and any involvement required by other groups (e.g., marketing).  As Dean Leffingwell once said, “don’t let something into the sprint without knowing how to get it out of the sprint.”

How to implement this whether using timeboxing or flow

There is not a set way to do DoRs or DoDs. What’s important is to have a conversation with everyone who gives or gets things from the team and decide on the agreements between all parties.


When these aren’t present, many handbacks will likely occur between the people handing work off.

Story about DoR

Around 2008 I was working with a client that was embracing Agile methods. I had a conversation with a small team about their work. They had been having trouble sometimes with building the wrong thing. I had a little conversation with them about this and if there was a pattern they saw. As they discussed this they realized the pattern was that they mostly had this problem when their product owner wasn’t available and they figured out things on their own. Looking back it seems kind of an obvious observation. But they hadn’t taken the time to see what was happening. The bottom line is that once they noticed it, they made a definition of ready to not work on anything until the product owner was available and validated what they thought they needed to do.

2.4 Capability: Attend to the customer journey while creating requirements.


The customer journey is the path the customer takes using the created system. When developing a product or service, what the customer journey will look like can be a helpful way to visualize what the product/service needs to be. The customer will not appreciate a poor customer journey. It is possible to go one step further, however. Imagine what the customer’s operational value stream could look like to improve their current operational value stream. While this can’t be imposed on the customer, attending to the customer journey can lead to better operational value streams.

The key thing to remember is – your goal is not to create systems, but to add value to the customer by attending to the customer journey.

Why this is important

Attending to the customer journey and the operational value stream is a kind of UX architecture. When done well, customers will enjoy using the product/service more.

How to implement this whether using timeboxing or flow

Quick feedback is necessary. So, if timeboxing is used, the team needs to set up frequent feedback sessions with the customers involved.

We should see how we define the customer journey that can positively impact the customer’s operational value stream.

This brings up the following questions on which to base our actions:

  1. What would an improvement be for the customer’s operational value stream?
  2. What customer journey would facilitate that?
  3. How can our development value stream attend to this?


When the customer journey is not addressed, the requirements will often not be high quality from the customers’ perspective. Using the system will likely appear awkward and not encourage improved operational value streams.

2.5 Capability: Agree on classes of service and their corresponding service level agreements


Different types of work require different agreements on how long it takes to build them. Each type of work is called a “class of service.”  Each class of service should have a service level agreement – that is, how will this class of service be handled.

Why this is important

It’s possible that it isn’t. In which case, you can have one class of service for everything. But then, at least you’ve agreed to that. In many cases, however, maintenance items are dealt with separately. Sometimes we need to understand what we’ll do when a severity-one error occurs (e.g., the system is down).

How to implement when using either timeboxing or flow

Essentially all that’s needed is an agreement on what is expected for each class service. This just has us understand how product owners and development teams work together


Without these agreements, expectations may not be appropriately set. This can cause both confusion, distrust, and waste.

Latest Article

Going From Scrum to Flow/Lean/ToC to Amplio

Start Reading >>

Latest Presentation

Intro to BLAST and How To Solve Challenges in the Workflow

Watch Video >>

Upcoming Event

An Introduction to Amplio - A Pattern Language (Free)

Register on Zoom >>

The Amplio Community of Practice (Free)

Learn More >>

New Workshop

The Amplio Development Masterclass

More Info >>

Latest Presentation

Intro to BLAST and How To Solve Challenges in the Workflow