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 moves it into the upcoming sprint backlog. 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 iterations 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 the most important feature, right now, to your customer. Their priority, not ours.

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. There is no situation in which you’ll say, “well, actually, this is more important than what you want.” If you find yourself in that situation, it means you and your customer are not communicating. The decision is theirs. All we can do is inform that decision.

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 sprints 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. The decision belongs to your customer — only your customer can tell you what is a priority. Step aside and let them make it. Support them, provide guidance as needed, and helpfully explain the impact of any decision.

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.

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 fit into a sprint — 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 doesn’t fit a single sprint, 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 sprint, 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. Sprint fitting. Add the feature to the upcoming sprint backlog by moving its work items into your sprint.
   1. If the feature clearly does not require an entire sprint, repeat the process with another feature.
   2. If the feature will likely consume the entire sprint (or more), move on to 3.4 Tactical event storming. There, fidelity will be added to your design and, if necessary, you’ll decompose the feature into smaller pieces to fill a single sprint.

Outputs

• Sprint backlog. A sprint backlog fully populated with your highest value feature.
• Backlog (optional). If the entire feature cannot fit in one sprint, some of the feature use cases may have been moved into a backlog for future sprints.

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