Making Promises You Can Keep to Customers

Effective Commitments Are Based on Features and Capabilities, not Stories

I recently answered a question about how product teams using Scrum should handle the business side: the side that promises functionality to customers, sets dates for demos or deliveries as commitments rather than targets, and wants to track that functionality as it gets built. How can the product team work with the business side to make and deliver on commitments to customers?

It's a good question, and the answer exposes something most organizations get wrong in how they think about both functionality and commitment.

First, two ground rules

Your organization should never promise deliveries inside of a sprint. Functionality is delivered at the end of a sprint after acceptance by the Product Owner, not during a sprint. And your salespeople should never promise a client something without engineering's commitment first. Making promises that only sales has signed off on is exactly how you end up in trouble with customers.

(I know, teams can develop the capability to complete and deploy 'done' items before the end of a sprint, but promising customers to do so creates significant risk because it relies on precise estimates, and the higher the precision of an estimate the less likely it is to be accurate. Releasing functionality to customers requires more than just delivery from the team, it also requires deployment and enablement and corresponding release-related work. If you truly need to release more frequently than your current two-week sprint cadence... and I would argue against this as a symptom of the tyranny of the urgent... reduce your cadence by shortening sprint duration.)

But promising deliveries inside sprints and having the sales folks commit engineering to delivery without asking first are symptoms. The real problem underneath is this: the organization doesn't understand what a release is.

Here's a quick test. If you've built three things and they're "done," they should be demo-able in the product, or at least in an internal test build. Are they? If not, why not? "Done" that can't be demonstrated isn't done; it's work in-progress. A release is not a pile of finished stories. It's a coherent set of benefits implemented through functionality that is deliberately enabled for, and visible to, users.

Why committing at the story or epic levels is risky

Reporting on a commitment should be easy. The reason it usually isn't is that teams try to commit at the story or epic level: discrete increments of functionality that may or may not make sense to customers and that, if deployed incrementally but not completely, may not offer sufficient value to users or be demo-able in a way that is coherent.

Let's talk about epics, briefly. As you know, a story is defined as a backlog item that can readily be delivered by less than a single team in less than a single sprint. The term epic came about as a bit of cleverness and a play on words; epics are backlog items that cannot be readily delivered by less than a single team in less than a single sprint and therefore must be decomposed into a sequence of component stories before implementation if we are going to follow good practice for backlog formation and ordering, and sprint planning.

SAFe, or the Scaled Agile Framework, as part of their planning doctrine, took the concept of epics and modified it to fit their planning model. SAFe uses epics at the portfolio/roadmap level. Using SAFe terminology, an epic is a significant increment of functionality that spans multiple Program Increments (PIs) and is delivered across multiple Agile Release Trains which may take multiple months or quarters. Fully delivering a SAFe epic can span multiple Releases (cadence-independent deployments to customers) and Versions (a baselined product configuration at a specific Release time). Epics in SAFe are intended to be decomposed into multiple PI-specific Features (specific functionality that fulfills a specific customer need and that can be delivered within a single PI). SAFe Features are further decomposed into component stories as part of PI Planning in SAFe. Thus, committing at the story level, or even the feature level, as defined by SAFe doctrine creates a risk in that what you've committed to may not provide the functionality that was promised to the customer.

Use StrataMapping doctrine to effectively commit at the FCE level instead

Contrast this with StrataMapping, a scalable planning and scoping approach that predates the development of SAFe planning doctrine by several years. StrataMapping is a user-centric functional modeling approach designed to help plan small or large projects by starting at the user's needs to develop an actionable plan in the form of an ordered product backlog that can be rapidly and efficiently delivered regardless of scale.

We can use the work hierarchy from StrataMapping doctrine to make effective commitments at the FCE level instead. FCE stands for Feature, Capability, or Enhancement. Here's the StrataMapping definitions for those terms:

• A Feature is an aggregate of user-accessible functionality that lets a user run a transformational workflow to obtain a benefit, e.g., spell-check, edit a document, manage a sales order.
• A Capability is an aggregate of functionality that may not be directly user-accessible but applies across the product to benefit users, e.g., multi-tenancy, role-based authentication, email broadcast services, a task scheduling engine.
• An Enhancement is one or more stories that can be released and add perceptible new benefit to an existing Feature or Capability.

Note that the FCE is the interface between a product roadmap and the product backlog; it's the smallest level of functionality product managers should care about, and the largest level of functionality the project team should care about. What about customers? Customers don't care about stories or backlog items. They care about benefits and we deliver benefits via FCEs. Internally, we care about stories only as a piece of the package that comprises an FCE. Because FCEs are discrete, definable, estimable, and measurable, you can track them across sprints and across teams, and forecast their completion quantitatively, with data straight out of Jira or Azure DevOps. Delivering an FCE is a commitment you can stand behind.

"Release" means enabled for users, not deployed

Here's the restatement that makes everything else work: deploying code and releasing functionality are two different events.

Modern teams ship code to production continuously and invisibly, behind feature flags or entablements. A release is the moment you flip the switch and enable a slice of functionality for an audience. That audience might be your internal testers first, then a beta group, then everyone. Good practice means the product team decides who gets access to what, and when.

Once you separate the two, a lot of anxiety evaporates. You don't have to hold code back to control a release; you deploy freely and enable deliberately. You can test in production before exposing a feature to users. The release plan stops being about "what's merged" and becomes about "what benefits are turned on, for whom, when."

Sizing a release: MMF and MRF

So how big is a release? Two concepts help to shape and size a release; the Minimum Marketable Feature, and the Minimum Releasable Functionality.

MMF: Minimum Marketable Feature. For each FCE, the smallest slice that genuinely creates user value and is worth turning on. Not the whole feature. Just the minimum that delivers the benefit. Getting this line right matters in both directions: too thin and the feature doesn't actually work for users; too fat and you've quietly padded the release with unnecessary scope that extends the release date and lost some of your ability to use scope as a steering mechanism for hitting the desired release date (more on that in a bit).

MRF: Minimum Releasable Functionality. A release is the aggregate of the MMFs of every FCE scheduled into it. That's it. A release is, at a minimum, its MRF.

This is why a strategy of a larger (but not huge) v1 release with smaller subsequent releases enables rapid delivery. To ship a useful first product, you need the aggregate MMF of the necessary FCEs. That large first MRF is effectively your minimum releasable product. After that, each release is often a single Enhancement to one existing FCE: a small, focused MRF.

Hitting the date using scope and slack to steer the release

A committed date is fixed by the critical path, which ideally is the duration to implement the FCE with the most scope to MMF. That FCE is 'the long pole in the tent,' so to speak. Understanding this is critical to developing a plan to effectively utilize multiple teams, working in parallel, to shorten the release duration and bring in the schedule. Ideally you could bring in one team per FCE, making the release duration the time needed to implement the largest FCE to MMF. Note that every team that reaches its FCE's MMF before the largest FCE reaches MMF has available capacity to do additional work, or slack.

That slack is your Product Owner's lever that can be used to steer the release to complete by the committed date. When a team finishes early, they have options:

• if there are essential FCEs that have not been started, start on them,
• if they can, help another team implement a lagging FCE to MMF,
• implement highly desirable 'nice-to-have' stories in their own or other MMF-complete FCEs to enhance the release as long as this doesn't push out the release date,
• if none of the above options are valid or offer sufficient additional value to justify the cost, then move on to other projects/releases

So, a release is a firm floor (the MRF) plus a discretionary, ranked ceiling filled by additional stories that may be implemented depending on excess development capacity (slack), against a fixed date. That's variable-scope timeboxing, and it's how you land a release on or before the committed date without either cutting essential functionality or letting a fast team gold-plate.

Two lines, two owners: the PO owns the release line (what's in, against what date); the PO and the team collaborate to set each FCE's MMF line (the team knows what "minimum to enable" really takes). Keep those honest and the plan steers itself.

Where StrataMapping comes in

All of this needs to be visible on one artifact. That's what a StrataMap is. It lays out your product as a functional hierarchy expressed as Users → FCEs → Steps → Stories, and then lets you overlay the release plan directly on top: mark each FCE's MMF, assign FCEs to releases, and the MRF for any release is just the set of MMF slices you scheduled. Turn on a release filter and you're looking at exactly what that release delivers. The optional stories for a release sit below the per-Step MMF line but above the empty band that separates one release from the next: still in the release, ranked and waiting.

One modeling note worth understanding. Capabilities (auth, email services, task scheduling engine) span the whole product, so they rarely belong to any single user role. Don't force them under one. Make the product itself a "user" on the map, strictly for cross-cutting Capabilities. It keeps the map honest about what's shared infrastructure versus what an actual user does.

A concrete example

Here's an abbreviated StrataMap of a community-website product that has been released to various customers. It has three users (the product-as-platform, the community member, and the committee administrator). The original map had 19 FCEs, ~190 stories, while we've simplified the StrataMap to have one FCE per user role: a capability that exposes the infrastructure build-out for a modern containerized web application under the product-as-user, then an FCE under each actual user.

The v1 release is the MRF plus optional stories under each FCE, as time permits, but we can release a viable v1 product as soon as every FCE in the release has reached MMF and we've produced a minimally functional site. It's everything needed for a site people can actually use: join the mailing list, read news, browse events, download documents, and find information, plus the admin tooling to produce that content and the platform capabilities (security, email delivery, data) to run it. The stories that sit below the MMF lines but still inside the v1 band are assigned to v1, ranked, held in reserve. The PO can choose to implement them if there's otherwise unusable slack or defer them to vNext.

The vNext release is a small MRF, roughly 20 stories: broadcast emails, event reminders, an FAQ manager, scheduled tasks. These are Enhancements: stories that couldn't be completed without extending the schedule, and that weren't necessary to get v1 out the door, and ranked below other stories that were judged to be desirable to include in the v1 release if time permitted, so they're deferred to vNext. After we release v1, the Product owner will adjust the vNext release, perhaps resetting MMF for vNext, perhaps creating an additional 'vAfter' release and partially scoping it.

Nothing here is a guess. Every FCE is discrete, estimable, and trackable; the release line and the MMF lines are explicit; the reserve is visible. When the business asks, "what are we committing to, and when," you point at the v1 band and answer in benefits, not in a burndown of stories no customer will ever see. And the StrataMap can be updated after each sprint by updating story status on the map from the execution tool so you can clearly see, show, and measure progress against the release plan. Thus, a StrataMap is not only a valuable scoping and planning artifact, it also continues as a valuable living artifact for communicating progress against plan. Any stakeholder can view the map, know immediately what has been implemented and what remains, whether an FCE has hit MMF, and if optional stories are being implemented and in what order. No one has to ask. It's just there.

Try it

If your release conversations are still happening in spreadsheets of stories, printouts of Jira queries, or if "done" keeps failing the demo test, try StrataMapping a product this way once. Do it manually... put your FCEs on the wall, draw an MMF line through each, pick a release, then check off stories as they're implemented.

If you want the benefits of StrataMapping without the hassle of sticky notes and the friction of keeping your StrataMap and your backlog synced, try the Explorer tier of StrataTree free to play with StrataMapping, or take advantage of the 60-day no questions asked refund policy to use the paid Product Owner tier of StrataTree to download your backlog from your tool, create a valid StrataMap from your backlog, and then to upload the optimized backlog back to your tool. You'll be able to commit at the level customers care about, steer to a date you can defend, show progress explicitly (and demo it), and forecast the rest with real data out of your execution tool.

That's what StrataMapping is for, and it's what StrataTree is built to do. If you'd like to be able to make promises to your business and your customers that you can keep, then this is where to start.