The team was doing exactly what they were asked.

What we were told

A development organization was struggling with productivity.

Work was taking longer than expected. Features reached review but were not being accepted. Releases were slipping.

From the product side, the explanation seemed straightforward: the development team was not consistently delivering what had been requested.

If that explanation was correct, the obvious place to investigate was engineering productivity.

What we observed

The team was working iteratively.

Before implementation, a story would be discussed and the expected behavior would be defined. The development team would then implement that behavior during the sprint.

The engineers were not ignoring those requirements.

They were implementing them.

The problem appeared later.

During review, behavior that had not been part of the agreed acceptance criteria would sometimes become necessary for the work to be accepted.

For example, a story might define one workflow for a particular operation.

At review time, an additional condition could be introduced: under a certain circumstance, part of that workflow should be skipped automatically.

In another case, the agreed behavior might specify how the system should inform a user when an operation failed.

At review time, the expectation could become that the system itself should recover from the failure without requiring the user to take that action.

In another, a preview capability might have satisfied the agreed criteria, only for an additional manipulation capability to become necessary during review.

Each request could be reasonable.

That was not the problem.

The pattern

The new expectations were not being treated as changes to the specification.

They were being treated as evidence that the development team had failed to implement the original specification correctly.

That distinction changed everything.

From the product owner's perspective, the requested feature had not been completed.

From the development team's perspective, the agreed acceptance criteria had been implemented—and new requirements were appearing after implementation.

The organization described the resulting delay as poor engineering productivity.

But the observable sequence of work was different:

1. Acceptance criteria were agreed.
2. The development team implemented them.
3. New expectations appeared during review.
4. The new expectations were not classified as changes.
5. The original implementation was therefore treated as incomplete.
6. The additional work extended delivery time.
7. The delay was attributed to engineering productivity.

Our hypothesis

The development team was not primarily suffering from a productivity problem.

The system used to determine whether work was complete was unstable.

The team could satisfy the acceptance criteria that existed when implementation began and still fail the review because the effective criteria had changed by the time the work was evaluated.

That creates a particularly difficult productivity problem to solve.

Improving coding speed does not fix it.

Improving tooling does not fix it.

Asking developers to estimate more accurately does not fix it.

Even making the team dramatically faster would only make them reach a moving target sooner.

Why the problem was hard to see

Nobody needed to be dishonest for this system to emerge.

The product owner could genuinely believe that the additional behavior was an obvious part of what had originally been requested.

The developers could genuinely believe that they had implemented exactly what had been agreed.

Both statements could accurately describe each person's understanding.

Neither statement, by itself, described what was happening to the work.

So we did not need to decide whose interpretation was correct.

We compared the acceptance criteria that existed before implementation with the expectations applied during review.

The difference was observable.

What the evidence showed

The reported problem was low engineering productivity.

The observed problem was that the conditions for accepting completed work could change after the work had already been implemented.

As a result, work that matched the agreed specification could still be classified as incomplete.

The team was being measured against requirements that had not necessarily existed when the work began.

That meant the apparent productivity problem could not be solved by optimizing the developers alone.

The developers were not failing to meet the acceptance criteria. The acceptance criteria were moving after the work was done.

The Pulsar view

If we had accepted the original diagnosis, we would have started by asking how to make the development team faster.

Instead, we followed the work from agreement to implementation to review.

The difference between what the organization called the problem and what the work itself showed us was the useful signal.

The stated problem was engineering productivity. The observable problem was elsewhere.