Years ago, I worked with an engineering team that was doing what a Scrum team was supposed to do. We planned sprints, estimated stories, and tracked velocity.
And every sprint, we seemed to have the same conversation.
A story wasn't quite ready when we started it. The acceptance criteria left room for interpretation. Testing uncovered things we hadn't accounted for. Work rolled into the next sprint, and we adjusted the plan again.
Nobody was sitting around doing nothing. The team was working hard. But we weren't getting much better at finishing work, and our velocity numbers weren't telling us what to change.
Looking back, I think we had become better at measuring our process than at questioning it.
A game that changed how we thought about stories
Around that time, we started exploring #NoEstimates and Kanban. The team wanted to try something different.
One of the things we did was play Elephant Carpaccio, an exercise created by Alistair Cockburn that helps teams practice splitting a larger feature into very small pieces that still deliver something useful.
I still remember the competitive spirit. People were trying to outdo one another by finding smaller and smaller slices. It was fun, which is not something I can say about every process-improvement exercise I've been part of.
But it also exposed something we'd been missing. Breaking a story into smaller tasks isn't the same as breaking it into smaller pieces of value. We couldn't find useful slices until we were clear about what the story was meant to accomplish.
We had to get more specific about acceptance criteria. Once we did, we could see ways to deliver something meaningful without waiting for the entire original story to be completed.
That changed the conversation. Instead of debating how many points a story was worth, we started asking how small we could make it while still delivering something useful.
We eventually switched to Kanban. Smaller stories, clearer acceptance criteria, and better visibility into work in progress helped us focus on finishing work rather than repeatedly carrying it forward.
Our average story cycle time dropped from roughly 20 days to 3. That was a substantial improvement. It came from several changes working together, not one methodology: reshaping the work, clarifying what done meant, and improving its flow. We were finishing useful increments sooner and getting feedback earlier.
What stayed with me wasn't the method. It was what happened when the team questioned the shape of the work itself.
Years later, AI made the problem familiar again
Years later, I was working with another engineering team. AI-assisted development had become part of how we worked, and engineers were finding they could implement things much faster.
But during a retrospective, a familiar concern surfaced. Stories were reaching engineers without enough clarity. Scope wasn't always understood, and developers were discovering unanswered questions after starting work.
I wanted to know whether this was an isolated frustration or a recurring problem, so I surveyed the team. The responses confirmed that story grooming needed attention.
The data led to some uncomfortable conversations with our Product partners. It wasn't feedback they were happy to receive, but it gave us something concrete to work through together rather than relying on opinions.
Product bandwidth was a real constraint. We also had engineers in Spain, with Product and UX colleagues in the US across two other time zones. A question that seemed small could leave someone waiting much longer than the decision itself should take.
We aligned on expectations for epic structure, story definitions, and defects, then turned those expectations into templates. Engineers took responsibility for breaking down every epic and updating the work as it progressed, drawing on the initial epic from Product, product briefs, UX designs, and experiment briefs where needed.
For larger epics, especially those expected to span several weeks, engineers wrote technical briefs. We reviewed them as a team and captured the important design decisions. That gave substantial work the attention it deserved without turning every small change into a formal review.
But templates and technical briefs weren't enough. We also needed decisions to happen closer to the work.
I encouraged engineers to make reasonable calls on smaller changes themselves, often offline, rather than waiting for approval at every turn. Tech leads had the responsibility to help unblock the team. Bigger decisions warranted a conversation with Product or UX, sometimes after standup, sometimes in a separate meeting. Knowing when to decide and when to ask was itself part of the judgment we wanted engineers to develop.
That required trust, including permission to make an imperfect call, learn from it, and correct course. In a team spread across time zones, ownership mattered as much as clearer documentation.
At the same time, we adopted and adapted practices from AWS's AI-Driven Development Lifecycle (AI-DLC). What appealed to me was that AI could do more than accelerate implementation. It could prompt engineers to think through questions before committing to a path.
What needed clarification with Product? Which design or architecture choices were equally plausible? What testing, data, or security decisions were still open? Instead of automatically picking an approach, the workflow could surface options for engineers to evaluate and discuss.
The team built and tuned its own AI-DLC repository, adding the relevant code repositories so a coding agent could work across them. We used the more structured workflow for larger changes, not every small issue. Code review remained manual through GitHub.
AI wasn't there to replace judgment. It helped engineers see the decisions in front of them, while the team had more ownership to make those decisions and bring in Product or UX when needed.
The difference was tangible. Engineers were no longer regularly stopped in their tracks for clarification. Work flowed more smoothly, morale improved, and subsequent retrospectives reflected the change. I don't have a comparable cycle-time figure for this team, but I saw the improvement in how people worked together.
Faster code is useful. Faster delivery is the point.
These experiences happened years apart, with very different tools. In the first, we needed to make work small enough to finish and learn from. In the second, coding had become faster, but unclear scope and slow decisions could still hold engineers back.
I don't think every story should be perfectly specified before development begins. Some things can only be learned by building. But there's a difference between discovering something new and repeatedly getting stuck on questions we could have addressed earlier.
That's why I'm cautious about measuring AI's impact through coding speed alone. If engineers can implement something in an afternoon but spend days untangling scope, waiting on a decision, or reworking assumptions, how much faster are we really delivering?
There's another question I keep coming back to: are we helping engineers make better decisions, or just execute decisions faster?
AI can help with both. But it depends on how we shape the work, who has the authority to make decisions, and when we bring others into the conversation.
I'm glad we can write code faster. What matters more is whether we can turn that speed into the right functionality, delivered well, and into customers' hands.