3.3 Identify product increment

Before we begin, let’s check our definition of ready. We’ll need artifacts created in previous activities:

Before starting

In 3.1 Value mapping we defined an increment as “the smallest amount of work that delivers a high-value feature into your customer’s hands.” This activity picks the single feature from the value map that delivers the most customer value right now and turns it into the upcoming increment. It’s usually quick when your value mapping was thorough. When it’s hard, the difficulty almost always comes down to a shared-understanding gap between customer priority, technical need, and what “feature complete” really means.

Three principles underpin the decision:

1. Keep the increment small. Short cycles put usable software into your customer’s hands as often as possible.
2. Ship it feature complete. “Done” means done — we don’t promise to come back and finish later.
3. Pick what matters most to your customer, right now. Value is theirs to define; the build decision is yours to make — and to back with evidence.

Inform, don’t insist

When I say “inform the decision” I mean we support the customer so they can make the right call. If they want a feature shipped but you know it needs a foundation first, explain why: “We can set up account management without encrypting data, but anyone could then access our users’ personal data. Plus we won’t pass HIPAA or SOC2. We can do it later — it’ll cost two or three times as much in time and effort, maybe more. What do you want us to do?”

There is no overriding your customer on what matters to them. The definition of value is theirs — if you find yourself arguing that your priority is more important than their outcome, you and your customer are not communicating. But deciding what to build next to deliver that value is your job, and you owe them the evidence behind every choice. Inform relentlessly; never steamroll; and never hide behind “the customer asked for it” when the evidence says otherwise.

Feature complete ≠ never enhanced

“Feature complete” means independently valuable and usable, not “never to be enhanced.” A login service that creates accounts, authenticates users, and lands them on a placeholder dashboard is complete — even if annotation features or complex account-deletion semantics arrive in later increments as new, additive work.

Guide to “identify product increment”

You’ll leverage the value map from 3.1 Value mapping, along with other design artifacts, to decide what the next product increment will be.

On the surface this is an easy activity, but it can offer challenges. Invite your whole team, including your customer, to the table. Your customer defines what’s valuable — only they can tell you what an outcome is worth. The build decision — what to construct next to deliver that value — belongs to the team, made in the open and backed by evidence. Support the conversation, explain the impact of every option and keep those two authorities distinct.

Goals and impact

This activity has clear goals that align with specific, long-term impact to the project. These are, respectively:

Inputs

1. Sufficient time and commitment from your entire team (the business, technical roles, and very importantly, your customer) to devote to the workshop.
2. Up-to-date descriptions of your use cases, key results and architecture foundation.
3. Complete security and compliance requirements, integrated into your use cases and system design.
4. A functional architecture describing your target state and elaborating on specific technologies and design decisions.
5. Both a value map and a risk map, providing clear understanding of the business and customer value each feature creates, its priority, and its risk.
6. The continuous discovery hypothesis log. Selection cites its verdicts: a validated hypothesis strengthens a candidate feature, and a killed one legitimately removes a candidate — that’s the discovery loop working, not a setback.

Process

“Size doesn’t matter” — we’re concerned with identifying the single feature that your customer values most highly. Since we haven’t yet done detailed engineering work, the feature may be too large to deliver in one short cycle — don’t worry about that yet.

Once we know what feature we’re aligning on, detailed engineering work in the next activity will flesh out finer details. If the selected feature is too large for a single cycle, we’ll decompose it in 3.4 Tactical event storming.

Right now, a “feature” is essentially synonymous with a single context (or a sub-context). It may be somewhat coarse-grained — refinement happens later.

Prepare

1. Identify your team and give them plenty of heads-up notice. You should be able to select your feature in a single session, but it could lead to refinement activity that demands more time.
2. It may be helpful to refresh everyone’s understanding of domains, contexts, and sub-contexts (especially for new team members). Refer back to chapters 2.4 Domain modeling, 2.5 Context mapping, and the companion article The 30-minute guide to Domain Driven Design.
3. Make sure the team is aligned on the purpose: select a feature for the upcoming increment, not dive deep into engineering.
4. Distribute background material, including all of the activity inputs (functional architecture, value map, risk map). Make sure everyone is familiar with the value map so time isn’t wasted revisiting prioritization.

Execute

This activity is generally quite straightforward, since — in theory — the hard work was already accomplished in your value mapping exercise.

1. Value map review. As a team, review the value map. The map identifies the features with the highest value. Since the value map is based on contexts and domains, these could be fairly large features and may need to be decomposed into smaller deliverables. (That happens in the next activity, 3.4 Tactical event storming).
2. Feature identification. Pick the feature in the upper-right of your value map — your highest value feature. This is what you deliver now.
3. Confirm increment value. Review the feature and its use cases, confirming it is the most highly valued.
4. Fit your cadence. How the selected feature becomes scheduled work depends on how your team runs:
   1. Flow (kanban). Right-size, don’t capacity-fill: decompose the feature until the first slice is small enough to move from start to production-ready in days, then pull it. WIP limits protect focus — the rest of the feature waits in the increment backlog, not in progress. When a slice finishes, pull the next.
   2. Timeboxed (Scrum). Fit the timebox: move the feature’s work items into the sprint backlog. If the feature clearly won’t fill the sprint, repeat the selection with the next feature. If it will consume the sprint (or more), continue to 3.4 Tactical event storming, where decomposition adds fidelity.

Outputs

• Increment backlog. The upcoming increment, populated with your highest value feature — a pulled slice in flow cadences, a sprint backlog in timeboxed ones.
• Backlog (optional). Whatever didn’t make this increment returns to the backlog for future cycles.

By focusing exclusively on customer value, in small, feature complete increments:

1. The delivery meets customer expectations and aligns with their priorities.
2. Perception of forward progress is protected.
3. Time to delivery is minimized.

In 2.3 Strategic event storming we developed event maps to describe, in detail, how our product behaves. In the next chapter we’ll add greater fidelity to those event maps as we transition into detailed engineering design — building out artifacts that describe exactly how all those business cases actually work.

Next activity

• 3.4 Tactical event storming