Your Kanban Board Ends Too Early

People are deploying a feature and calling it a day, essentially. The problem is that while the feature might be working, it might not be useful. Or even if it’s useful, it might not be used. One specific scenario I’m seeing when working with AI enablement leaders is that they’re working on AI use cases: they are deploying agents, deploying Gems, and nobody’s using them. It’s not really useful that way.

What follows from treating deployment as done is that nobody pays attention to whether people are really using it. Nobody’s really working on getting value, getting an impact from the thing. The card left delivery, so the important part is over.

What I typically do in these cases is suggest adding a column to the board, where the criterion for entering it is that we believe the thing is useful and we believe it’s ready to be used, and the criterion for leaving that lane is that we have evidence that people are actually using it. That’s very simple. It’s not a huge change. And what I’ve seen in organizations where we’ve added this (the marketing team that added real learning to their flow is the written-up example) is that just adding that lane forces the interesting conversations.

Where a board effectively ends reflects a mental model of siloed thinking, I would say. Take the column names off and just look at the last state. It doesn’t take into account the realization that real value crosses value streams, or crosses multiple functions throughout the value stream.

With AI enablement work this shows up in a starker form, because a lot of it has never been given a lifecycle at all. What I see with a lot of AI enablement situations is that they don’t even look at the end-to-end picture. They don’t even consider the end-to-end lifecycle of an AI use case. They don’t yet apply the product lifecycle, or something like a product lifecycle, to this work. And if they did, it would be just focused on delivering the AI agentic lifecycle capability, including anything related to adoption or fine-tuning.

When I walk into an organization and ask to see the board, the thing I rarely see is a Learn stage.

What makes that expensive is not that the organization is guessing. The organization is not even seeing it as guesswork. They’re just moving on. The fact that this stage is missing means that, essentially, they’re moving on to other things. So the feature might be deployed, but it’s not really providing the potential value.

Somebody is still carrying that risk, and it’s the users. They’re getting features that aren’t necessarily fit for purpose for them, which means they’re not necessarily using them. And the team is not necessarily getting closer to the outcomes that they are responsible for, assuming that they’re responsible for outcomes. In other cases the teams are not responsible for outcomes, but the organization is responsible for outcomes, and it’s not really seeing those outcomes.

If you feel you have an adoption gap and you want to focus on it, it’s really the telemetry. From the moment there’s telemetry, we’re in the stage of understanding where the friction points are, and it could be that there’s an actual sprint where you don’t develop anything, only telemetry, and you go and watch the users and try to understand what’s blocking them.

Here is how that plays out. I was recently working with an AI enablement lead running an agentic development lifecycle across a set of teams. The technical side was working, and this is exactly the stage where, beyond the technical solution, we’ve passed the point where the technical works and we’re now in the hypothesis of whether the users are using it. So concretely, what are you doing about it? First of all, do you have adoption measurements? They didn’t. They knew how it was going from what people told them.

The backlog aimed at adoption was demo sessions, showing examples, giving people an incentive to use it, and usability improvements to the framework. All of that pushes the capability at people. None of it says whether anyone is pulling. So alongside the telemetry, on every feature, both the ones you’ve already done and the new ones, make sure that as part of the lifecycle, there’s an adoption stage.

You’re not going to get anywhere close to the 10x if you’re just improving output in a certain area. Organizations right now are aiming to improve, and there’s the promise of the 10x, so organizations that want to fulfill the promise of AI leverage need to look end-to-end. Otherwise, all they’ll be able to show is local improvement.

The main thing is that AI accelerates some stages dramatically. Because of that acceleration, there’s the potential to create bottlenecks even faster, or more and more stuff to pile up in between the stages. You can see both halves of that on a cumulative flow diagram. Since implement keeps growing and growing, it means I have extra implementation capacity that isn’t reaching Done. It keeps sitting there in progress, and if I split the statuses a bit more I’d have implement and waiting for code review. And another pattern: when I do manage to send things out, I don’t really manage to close the loop in adoption, in monitor-adapt-learn. Things get stuck at that stage a lot of time too. The same team had planned the next quarter on a twenty to thirty percent velocity gain that was assumed rather than observed, because adoption was still partial. That’s wishful thinking.

Their leaders don’t care about that local improvement. Maybe for right now they are able to get away with it, and that’s part of what we’re seeing right now: people are getting away with local improvement. But over time, leaders will become smarter and start to expect the actual outcome, the actual impact. They’ll expect it end-to-end. It won’t be enough to just say development is faster and we’re creating much more code and we have many more PRs and maybe even we’re code-reviewing the PRs. That’s not going to be enough.

Concretely, what I usually do is create an epic lifecycle, a Kanban board of the epics that manages the life of the epic. We prioritized it, and now it’s in planning, and now it’s in work, and we released it, and now we’re working on adoption. And we don’t close it until we’ve made sure that the adoption is as we want it. Putting that state specifically in the lifecycle really helps to focus on it. Keep it on the epic rather than the story, because with a harness a story can open and close inside an hour, which is the wrong altitude to hold an adoption question.

A limit on that state also sends a signal: don’t start new features, take care of adoption before starting new things.

And it can be interesting to look now, in hindsight, at the things you closed that are Done, and see whether there is already adoption of this feature, of this epic, or not. Even to move things and say: we have things that are fine, we have things we don’t know, and we have things we know are not. That can be an interesting exercise.

The learning is worth doing at more than one point, too. You can do compound learning at the stage of having working software, and also at the stage after adoption. Basically at every stage it’s worth doing learning.

Too many states is a real cost, and it’s usually the first thing I cut. Looking at a board with too many states for that team, where another team’s is simpler, the move is to simplify: every organization and its Jira. So this is one lane, on one class of work, not a board redesign.

The wait it makes visible was already there: the feature might be deployed, but it’s not really providing the potential value. And the limit on that state is doing deliberate work rather than adding drag: don’t start new features, take care of adoption before starting new things. In that same team the flow problem was nowhere near this lane: implement kept growing while Done didn’t, and most of that band was really waiting for code review.

I think it’s a choice. If you don’t have time for this, then you’re wasting your time on other things.

One lane, one class of work

Released -> Adoption / Learn -> Outcome Confirmed

Entry: we believe the thing is useful and it's ready to be used.
Exit:  we have evidence that people are actually using it.

The backfill exercise

Take the epics already closed as Done, give them the state they never had, and sort:

1. Adoption confirmed
2. We don't know
3. We know there isn't any

Pile 2 is the finding.

Prompt for an AI coach

Help us inspect this work without treating release as success.

Separate what we know into output, outcome, and impact:
- Output: what was shipped, enabled, or introduced?
- Outcome: what behavior changed, for whom, and how do we know?
- Impact: what business indicator should move if this outcome matters?

Flag where we have evidence and where we only have a hypothesis. Suggest the
smallest next observation or experiment that would raise confidence. Do not
recommend building more until the current learning gap is clear.

Preference snippet

For a team constitution, working agreement, or AI preferences file:

Do not treat release as success for product bets, AI initiatives, or workflow changes.
Ask what behavior changed before claiming value.
Ask what business indicator moved before claiming impact.
If the evidence is missing, define the smallest next observation or experiment.

The AI Traction Scorecard is a quick way to see where you stand.

Does the setup of your board ensure that what you’ve done has moved the needle on behavior, or has just delivered? Does your board stop at deliverable and output, or does it go towards outcome: the changed behavior for somebody?