It is one of those Product activities that everyone knows matters, yet it's routinely underdeveloped or written too late.

Your team has probably already used AI to write acceptance criteria.

You typed in a user story, got a list of conditions back, and pasted it straight into Jira. Fast. Easy. Done.

Here’s the thing, though. This speed comes at a cost.

I have seen that this acceptance criteria is usually vague, with missing edge cases and conditions that can’t actually be verified.

AI can write AC. That part is easy. Writing AC your team can trust is a different story.

Used without a clear process, AI gives you false confidence. The gaps are still there, they're just harder to spot.

In today’s post, I am going to give you a simple 3-phased process my teams use to write acceptance criteria every sprint.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Last Thursday, we learned how the POs use AI to turn vague signals into refinement-ready backlog items.

When this is done right, your PO can start the refinement sessions with:

1. a categorized signal,

2. a one-paragraph problem statement, and

3. a selected user story

But what if it is NOT done right?

Then what?

If you are a Scrum Master, how would you help the PO with this process and ensure it happens consistently?

Before we get into the mechanics of this, let me clarify something:

Your job as a Scrum Master IS NOT to run the AI prompts. Your job is to ensure the prompts are run by the PO and the team on a regular basis.

And to do that, you need to know:

• exactly which prompts exist,

• what each prompt produces, and most importantly

• when to push the PO to use the ones they’re skipping

That’s what this post gives you.

There are 13 prompts in this AI discovery toolkit, organized across various groups.

For each prompt, I’ve added a single pre-refinement question that you can use as a trigger to nudge your PO in the right direction. You don’t need to become a prompt engineer. All you need is to know the right question to ask.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Every refinement session has a tax.

The first 20-30 minutes where the team figures out what they’re actually building, why it matters, and whether it’s even the right thing.

That tax is paid because, usually, the PO walks into the Refinement sessions with a vague signal and not a prepared backlog item.

On Thursday, I showed you how some of the POs I work with have started using AI to turn such vague complaints/signals into refinement-ready backlog items in three steps, before the team ever gathers for the Refinement session.

Today, you get the template and facilitation guide to actually run it.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Here’s a typical refinement session:

Someone complains: "Users are saying they can't find anything in the app. Sales is losing deals over it."

The team comes together, one team member reads the complaint (or a vague requirement, or an idea, etc.) aloud, and for the next 40 minutes, the team tries to figure out:

• WHAT the problem actually is,

• WHOSE problem is it, and

• whether this is even the RIGHT THING to build

The effort is usually parked or rushed because “the thing” is not yet ready for refinement, and other items are lined up in the queue.

This happens because that complaint or requirement is a vague signal, and the work of turning it into a clear backlog item usually falls onto the PO.

Most POs do this in their heads between meetings, which results in a vague complaint becoming a vague user story.

This is now being changed thanks to AI.

Some POs I work with are using AI to quickly and easily turn these kinds of vague ideas into refinement-ready Backlog Items.

Here’s how they are doing it.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Welcome to the Sunday edition of the Winning Strategy Weekly Recipe.

This past Thursday, we discussed the risks my team encountered when using AI for backlog refinement.

Specifically, we looked at how AI behaves and how it confidently generates acceptance criteria, system behaviours, and trade-offs that look completely plausible but are often fabricated.

I shared the 7 essential guardrails my teams use to ensure the tool accelerates the work without taking decision-making ownership away from the team.

But understanding the guardrails and operationalizing them in an Agile environment are two different things.

To benefit from AI without the rework, we need a system that translates those principles into steps during our live sprint cadence.

This post bridges that gap.

You receive an artifact pack that you can add to your backlog workflow today, enabling your team to use AI for refinements with minimal risk.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

YES, we did.

And it went great… for about two weeks.

Then we spotted a problem.

The risk of using AI for refinement is that it sometimes produces bad output that is indistinguishable from good output.

I've spent a lot of time thinking about where AI helps in product discovery and delivery, and where it introduces risk that teams don't see until it's too late. In this post, I share 7 guardrails that are essential for any team using AI for backlog refinement.

I have conducted these tests across various refinement sessions, with multiple teams iteratively enhancing them.

Before I walk through each one, I want to name the one underlying principle that forms the basis of every guardrail.

Here it is. 👇

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

There’s a famous Bezos-ism that I think about a lot:

“Your margin is my opportunity.”

The idea is that wherever there’s inefficiency in a system, there’s an opportunity for someone to build something better.

Status meetings are exactly that. They are pure margin. They’re organizational overhead. And the opportunity is to replace them entirely with something that is async, consistent, and… let me say it… AI-generated.

In this post, I will share the system I've seen some Scrum Masters using to generate AI-powered reports for executives and stakeholders.

And let me tell you… they’ve been quite successful doing it.

But…

Before we kill the STATUS meetings and replace them with AI, we have to understand what the STATUS meetings are actually used for.

What’s their purpose?

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

The idea was simple:

Spikes shrink estimates ONLY WHEN they shrink the solution space, not when they confirm a solution exists.

What we need is a “Decision Spike.”

A Decision Spike is a session where we focus on clearly defining what will be built, what won't be, and the clarity needed to keep the timeline on track.

In today’s weekly recipe, I’m sharing the template to help you run a workshop for a Decision Spike.

It’s a 60-minute (time may vary) session that takes a stakeholder request (often a vague request) and turns it into confirmed increments with estimates, assumptions, and (most importantly) clear NOT-TO-DOs.

Note: This is more of a scoping session than a sprint planning. It's a great opportunity to get a clear understanding of a request as it first comes in, ideally before anyone starts writing anything.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Robert Falcon Scott’s team did extensive preparation. They studied the terrain, tested their equipment, and built confidence that the journey was technically feasible. They knew they could make it.

Roald Amundsen’s team did something different. They picked a specific route. They pre-positioned supply depots at exact coordinates and decided, before they left, what they would NOT bring with them, what they would NOT attempt, and what had to be true at each checkpoint for the expedition to continue.

Scott’s team proved the trip was possible. Amundsen’s team defined the trip they were actually going to take.

Scott’s team didn’t succeed.

Why?

What happened?

If you are new to Winning Strategy, check out the posts below:

1. Weekly Recipe: The PO Q&A System

2. How to deal with the one difficult team member in your scrum team?

3. Weekly Recipe: How to deal with the one difficult team member in your scrum team?

4. How to prioritize defects when everything is critical?

5. Weekly Recipe: Prioritize defects when everything Is critical

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

The Spike for estimation problem is a Strategy problem

We all know about spikes?

If you haven't encountered it (lucky you, in some ways), here's the short version:

When a team faces a major technical unknown, they timebox a few days to build a quick prototype and determine whether the scary thing is actually scary.

If you want to explore the topic further, I have written a post on Spikes that you can check out at the link below:

It's a genuinely good idea.

It comes from the Extreme Programming tradition, it's battle-tested, and mature teams use it all the time.

Here's the thing, though. Spikes don’t always deliver something!

A team runs a spike. The spike succeeds, BUT the estimate doesn't change.

The prototype works.

But when the team sits down to estimate the actual time, the range is just as wide as before. The team is still unsure about the requested time commitment.

How is that possible?

It’s possible because most spikes (in general) solve for the Technical uncertainty. And that distinction between the uncertainty you think you have and the uncertainty you actually have turns out to be one of the most interesting (and underappreciated) dynamics in product development.

Let me show you what I mean.

Story of a mature team

A product team I worked with needed to ship enterprise SSO. Azure AD integration (to be precise) for a big B2B prospect.

Leadership wanted an answer to:

“Can we commit to delivering this in 6 weeks? Yes… or No?”

The team did what any experienced team would.

(1) They timeboxed a spike (3 days). (2) They picked the riskiest technical area (OIDC/SAML. (3) They aimed to “remove uncertainty.”

Which uncertainty? The technical one.

This was the output (what they delivered):

• a prototype that successfully authenticated against Azure AD in a sandbox

• a short document stating: “We can use OIDC; libraries exist; token validation is straightforward”

• a diagram of the auth flow

The spike worked. But the estimates?

They had no estimates.

They still had NO answer for how much time this will actually take to be production-ready.

Stakeholders were confused: “But you proved it works, why can’t you estimate it now?”

What went wrong?

The spike answered one question:

Can we technically authenticate against Azure AD?

Yes. Definitely yes.

But that question was never driving the estimates.

The estimates depended on a certain kind of uncertainty. The kind that involved a long list of decisions and dependencies.

Things like:

• Do we need just-in-time user provisioning or SCIM or manual invites?

• How do Azure AD groups map to internal permissions?

• How do we handle multiple enterprise tenants and domain discovery?

• What does the security team require before anything goes live?

• What happens with disabled accounts, renamed emails, and duplicate identities?

• Can we roll out per customer behind a feature flag?

• What does the support team need for the inevitable Monday morning "SSO is broken" fire drill?

None of these is a technical feasibility question. They're decision questions. Policy questions. Cross-team coordination and dependency questions.

Technical uncertainty is the easiest uncertainty to identify, so it is the uncertainty that gets most teams Spike. But estimation uncertainty is usually dominated by scope ambiguity, unknown decisions, and external dependencies.

A spike on Technical uncertainty does approximately nothing for the Estimation uncertainty.

Understand it like this:

Let’s say you're trying to estimate how long it'll take to drive from New York to Los Angeles.

The unknown in your mind is "can my car handle the Rocky Mountains?"

So you test the car on a steep hill. It handles it fine. Great.

Can you estimate your trip?

No!

Why?

The reason you can't estimate the trip is because you haven't yet decided whether you're stopping in Chicago, you don't know if the highway through Kansas is closed, and your friend who's supposed to meet you in Denver hasn't confirmed dates.

The car works. But the trip is still unplannable.

Why did the experienced team get this wrong?

This is the part I find genuinely fascinating, because each reason below corresponds to a different type of cognitive bias.

#1: Knowledge Without Decisions

The team above came back from the spike saying, “We can do OIDC. We could map groups later. We might need SCIM depending on customer requirements.”

Could. Might. Depending.

There's a concept in strategy called "real options," which is the idea that maintaining flexibility has value. And it does! In certain contexts.

But when you're trying to estimate something, optionality is the last thing you want.

Every open option multiplies the “solution space.”

The team were estimating a decision tree. And the expected value of a decision tree with seven unresolved branches is... wide.

#2: No Constraints

The team didn’t decide the Scope.

No one locked down statements like:

• “Phase 1 will not support group-based roles”

• “Phase 1 supports one tenant per customer”

• “Phase 1 is invite-only; no SCIM until Phase 2”

Without constraints, every “maybe” stayed inside the estimate.

As a result, estimates remained vague because, for stakeholders, “done” still meant “everything enterprise customers might want.”

#3: Ignored Dependencies

In most teams, the most likely thing to blow up the timeline is WAITING.

Waiting for:

• security review lead time

• infra changes (redirect URIs, secret storage, cert rotation)

• customer IT coordination (metadata, app registration, testing windows)

The spike the team performed didn’t secure any commitments or timelines from those dependencies.

As a result, the team still couldn’t forecast dates because the critical path was dependent on 3 different teams… Security, Infrastructure and IT.

How did they fix it later?

The team re-ran the spike.

They now had a clear goal in mind for the technical spike:

"By Friday, the spike will help us know exactly what we are shipping in Phase 1, what we are clearly not shipping in Phase 1, and what external conditions must be true for the timeline to hold."

Here’s what the Spike looked like:

Timebox: 2 days

Inputs from: Product + Delivery Lead + Security rep + one engineer

Decision to make by the end of the spike: What is “in scope” and what is “out of scope” for a 6-week timeframe (Phase 1)?

For example:

Scope:

• OIDC only (no SAML in Phase 1)

• No SCIM in Phase 1

• Role mapping is manual (group sync deferred)

• Per-customer feature flag rollout

• "Done" = audit logging + v1 support runbook

Evidence required:

• thin vertical slice in staging with auth, feature flag and logs

• lightweight security sign-off via threat model checklist

• written non-goals included in the epic

Phase 1 (6 weeks) backlog change required. Splitting the epic into 3 increments with separate estimates:

• Increment 1 (2 weeks): SSO login behind flag, single tenant

• Increment 2 (2 weeks): Admin config, audit logs, runbook

• Increment 3 (2 weeks): Role mapping and SCIM (later)

Estimating this was straightforward.

🎯 Weekly Recipe

Stay tuned for Sunday’s Weekly Recipe, where I’ll share a step-by-step guide for running decision spikes, including templates and facilitation tips.

What did the team learn?

Let’s zoom out for a second

In strategy, there’s a distinction between learning and committing.

Both are valuable. But they serve different functions, and confusing them leads to a very specific kind of organizational frustration, the feeling that you’re doing all the right things and somehow not making progress.

A traditional spike is a learning tool. It says, "We don't know if this is technically feasible, so let's find out." It works great when technical feasibility is the binding constraint.

But on most mature teams, building the thing is rarely the constraint. The binding constraint in such teams is deciding what to build, coordinating external dependencies, and defining what "done" means in a way everyone agrees on.

So the team needs a technical spike that can help them make these decisions.

A Decision Spike.

A decision spike is a commitment tool. It says,

"We have enough information to decide. The decision will help us reshape the backlog."

So, how do you tell if your spike will actually help?

Here's a simple test.

Spikes increase estimate accuracy ONLY when they shrink the solution space. Which means it should produce at least one of the following:

1. A decision (we chose X, not Y)

2. Constraints/non-goals (we will not do Z in this release)

3. The smallest shippable slice (this is what ships first)

4. Dependency commitments (security/infra/customer IT: who, what, when)

5. A rewritten backlog (split stories/epics that reflect the new decision)

If your spike does not end with the above, then that's research. Research is valuable! But it won't result in an accurate estimate.

Next time your team raises an estimate spike

Even experienced teams can fall into the trap of running spikes that feel productive but fail to answer the required question.

Next time someone proposes a spike for estimates, ask this:

“What uncertainty will this spike remove, and how will that reduce the range of our estimate?”

If the answer is clear, run the spike.

If the answer is vague, i.e. “we’ll learn more about the problem space,” that’s fine, but set expectations accordingly. You probably won’t be able to provide estimates.

The bottom line: spikes help in estimates when they shrink the solution space, not when they confirm a solution exists. The best teams don’t just spike the technical risk. They spike the ambiguity. And those are almost never the same thing.

That’s it for today!

So…Why Scott’s Team Didn’t Succeed

Let’s close the loop on the story we started with.

Why didn’t Robert Falcon Scott’s team succeed in their race to the South Pole, despite knowing the journey was technically possible?

Because Scott’s team ran a Technical Spike, while Amundsen’s team ran a Decision Spike.

Scott’s preparation proved that the equipment worked and the terrain could be crossed. But just like the engineering team that proved OIDC authentication worked in a sandbox, Scott’s team gathered Knowledge Without Decisions.

Amundsen, on the other hand, shrank his solution space. He committed to one method of transport (dogs). He defined strict non-goals (leaving behind anything that wasn't absolutely essential for survival and speed). He secured his dependencies by laying depots at exact, mathematically calculated coordinates before setting out

In short, Scott confirmed the expedition could work. Amundsen defined exactly how it would work.

The result is what we all know.

Show your support

Every post on Winning Strategy takes a few days of research and 1 full day of writing. You can show your support with small gestures.

Liked this post? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone who would find this helpful? Make sure to recommend it.

I strongly advise that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.

Further Reading

1. SPIKES - 101

2. Non Functional Requirements are Ignored

3. I spotted 9 problems in a healthy looking team backlog

Connect With Me

• Connect on LinkedIn (I publish every Monday, Tuesday, Wednesday, Thursday and Friday)

• Connect on Community Chat

• Connect on YouTube

Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America’s largest banks.

Leave a comment

On Thursday, we discussed the pitfalls of the “everything is critical” backlog and why misunderstanding Severity and Priority can destroy a team’s ability to deliver.

We talked about the "Homeland Security" trap of defect management, where every defect is labelled 'Critical' or 'P1'. When everything is on fire, your backlog becomes a busy suggestion box, and your team loses the ability to actually prioritize.

If you missed it, here’s the link.

Knowing the theory, however, is only half the battle. The actual challenge is walking into that triage meeting on Monday morning, facing new defects, and actually changing how your team and stakeholders operate.

That’s exactly what today’s recipe is for.

Below, you’ll find the exact templates, facilitation steps, and metrics you need to implement this two-knob system, plus a few hard lessons on what didn’t work when I first rolled this out in the trenches.

Let’s dive in.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

If you are anywhere from North America or have lived here for some time, then you might remember the Homeland Security Advisory System?

After 9/11, the US government introduced a colour-coded threat level to tell Americans how scared to be on any given day. Green meant "low risk." Red meant "severe."

It was a clean, simple communication tool.

Nevertheless… it failed!

Why?

Because the threat level sat at Yellow ("Elevated") for essentially its entire existence.

It never ever dropped to Green or ever hit Red. It just… hovered in the upper-middle of the scale, permanently, for years, until the government quietly replaced it in 2011 because people stopped paying attention to it.

It failed because a label that’s always “Yellow” communicates nothing.

I bring this up because there's a very good chance your engineering team is running its own version of the Homeland Security Advisory System right now, except instead of terror threats, it's defects.

Just like the terror threat level was mostly “Yellow,” the defects are almost always Sev-1 (or P1) and critical.

“Critical” has become a catch-all label.

And once everything is critical, the team loses its ability to make trade-offs and decide what to fix first.

In this post, I discuss how I have seen mature teams address this problem.

This will be followed by the Weekly Recipe on the coming Sunday, which you can download and apply directly to your team.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

I’ve been the person asking the questions. The person dodging the questions. The person who didn’t even realize there were questions until everything was on fire.

So believe me when I tell you that “I’m always available for questions” is one of the most dangerous sentences in product development.

Don’t get me wrong.

The Product Owner is a good person trying to do a good job. The development team is a capable group of people trying to do their best jobs. And somehow, with all of that goodwill in the room, the team struggles to get timely answers.

Why?

Last Sunday, I announced a new format for the Winning Strategy newsletter:

• Thursday posts: Actionable insights

• Sunday posts: Weekly recipes (template + facilitation guidelines + what didn’t work (for us) + metrics)

Since this is a Thursday post, it will provide insight into this particular why.

Why… even when the Product Owner says they’re available for questions, the team struggles to get timely answers.

Let’s get started.

If you are new to Winning Strategy, check out the posts below:

1. How to transform your working agreement into a conflict operating protocol?

2. How to help your team avoid rework

3. Autonomy vs Commitment

4. How to eliminate dependencies?

5. Why Does Your Team Feel Busy But Deliver Nothing?

6. Is AI going to kill estimates?

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Let’s define the problem

Imagine this: I bet you’ve gone through something similar at some point.

Monday morning. Standup. A developer mentions they’re unclear on how a feature is supposed to behave. The Product Owner says, “Hey, just ping me. I’m always around.”

Monday afternoon. That developer pings. He has been heads-down building. He didn’t get a reply from the PO. The developer made an assumption around 1:30 p.m. and kept going.

Friday. The assumption turned out to be incorrect. The feature also has issues. The sprint review doesn’t go as planned. Everyone feels frustrated.

Is this a communication problem? I know it looks like one. It isn't.

Then what is it?

Availability is not a gesture

Saying "I’m always available" is a nice gesture. It is just a nicer way of saying "I don’t know when I am available."

Let me give you an analogy that's going to sound ridiculous, but stick with me.

I want you to think about how a restaurant works.

You don’t walk into the kitchen and tap the chef on the shoulder. There’s a system. You sit, you order, the order enters a queue, and the food arrives. It is predictable and reliable.

Now imagine the chef says, “Just come find me whenever you’re hungry.”

That’s what “I’m always available for questions” really is.

It puts the burden of initiation on the person who needs help, and the burden of context-switching on the person giving it. The question has to compete with meetings, stakeholder escalations, Slack requests, and whatever deep thinking the PO was in the middle of.

So PO responses become inconsistent.

PO does care, but there's no system to deliver the response in a timely manner.

As a result, the team begins to hesitate. They ask late. They ask in three different places. Or they stop asking altogether and just guess.

Good intentions without proper process produce the same result as no intentions at all.

So…

The problem we have just defined is not a communication problem. It is a process problem, and you can see this clearly when you look at the following patterns.

#1: The questions generally have no place to live

A developer asks a question in a Jira comment on Tuesday.

The PO answers that question in a Slack thread on Wednesday.

A different developer asks the same question in standup on Thursday because they never saw this exchange of question and answer.

The PO answers again, slightly differently this time, because the context has changed.

Now there are two answers in two places, neither of which is attached to the story where the work actually lives.

When questions and answers spread across Slack threads, Jira comments, meeting notes, DMs, and hallway conversations, you don’t have a communication system. You have a scavenger hunt.

And the next person who picks up that story in two sprints, or two months, will find… nothing!

#2: Nobody tracks how long questions sit unanswered

Teams are great at tracking stories, bugs, deployments, velocity. But almost no one tracks how long a question sits without a response.

As a result a requirement question that’s been unanswered for 2 days doesn’t appear anywhere… until it surfaces as rework or sprint spillover.

When this happens, you’ll notice people saying, “We didn’t realize it wasn’t clarified.” Because there was literally no process to make that visible.

You can’t manage what you can’t see, and decision turnaround time is one of the biggest invisible bottlenecks in sprint delivery.

#3: Most "quick questions" actually involve hidden decision-making

Let’s say a developer asks: “Should the confirmation email go to the account owner or the billing contact?”

Seems simple.

Except that the PO knows that different stakeholders have different opinions, nobody has aligned yet, and answering this “quick question” actually requires a trade-off conversation with two other people.

What you’ll notice: Answers that arrive are either partial decisions or are delayed by one or two days.

Many questions that appear to be clarifications are actually scope calls, trade-offs, or policy decisions in disguise. And “I’m always available” doesn’t help when the answer requires coordination, not just knowledge.

#4: Decision authority is undefined

Here’s a question you must ask your PO: “Which questions can you answer on your own, and which ones do you need to escalate?”

If the PO doesn't know the boundary…

They’ll treat every question cautiously. They’ll delay and will say, “Let me check.”

If the team doesn’t know the boundary…

They can’t tell the difference between a ten-minute answer and a three-day stakeholder alignment exercise.

So they wait. At the same pace. For everything.

This is fixable in one conversation. Most teams never have that conversation.

#5: The PO waits for certainty before responding

The PO wants to give the right answer. Not a guess. So they wait until they’re sure. Which means the team waits, except the team does not know that it is waiting.

In most cases, a “provisional answer” is infinitely more valuable than a perfect answer that arrives two days late.

But nobody told the PO that a “provisional answer” was an option. Nobody gave them the language for “here’s my best call right now, safe to build on, and here’s what we’d redo if it changes.”

They don’t want to sound negligent.

So they stay silent out of a sense of responsibility. Which is frustrating, because the responsible thing is actually causing the damage.

Here's what works in such situations

Start thinking of the PO’s availability as a service that needs to be designed.

Just like in restaurants.

A well-designed answering service has three properties:

One intake point: A single, agreed-upon place where questions go. If it’s not there, it doesn’t exist.

A response promise: A specific, realistic turnaround time. Not “as soon as I can.” An actual number.

A visible outcome: The decision gets documented in Jira. Not in a Slack thread that disappears by Friday.

When teams adopt this approach, they stop trying to “communicate better” and start reducing blocked time and rework, which is measurable.

It’s a small change, but it produces surprisingly good results.

Coming this Sunday

This Sunday’s Weekly Recipe will include a ready-to-use template called The PO Q and A System, including:

• the intake process,

• triage scripts,

• SLA options,

• a lightweight format for documenting decisions inside story tickets

You can copy and adapt it.

You’ll be surprised by how much delivery friction comes from this one blind spot and how quickly it clears up once you give it a little structure.

Have a great week, and I’ll see you on Sunday ✌️

Show your support

Every post on Winning Strategy takes a few days of research and 1 full day of writing. You can show your support with small gestures.

Liked this post? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone who would find this helpful? Make sure to recommend it.

I strongly advise that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.

Further Reading

1. Product Owner Doesn’t Attend Scrum Events!

2. First 30 Days of a Product Owner - Complete Schedule

3. Product Owner Onboarding - Training Deck

Connect With Me

• Connect on LinkedIn (I publish every Monday, Tuesday, Wednesday, Thursday and Friday)

• Connect on Community Chat

• Connect on YouTube

Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America’s largest banks.

Leave a comment

The Product Owner walks through a story, asks, "Any questions?" and gets nothing but silence.

It's one of the most common frustrations I hear from Agile teams.

Developers are not asking questions.

But why?

The most common reason people have found is that their environment, the way the stories are presented, the format, the culture, all of this, is telling them not to.

Refinements are intended to get developers to ask the right questions at the right time… before the code is written.

In practice, however, refinements are quiet. Product Owner reads a ticket aloud, developers nod politely, and everyone disperses to "figure it out during dev."

Then, two weeks later, there is rework.

How do we fix this?

In this post, I'll share 9 practical techniques for creating conditions that naturally surface the 10 clarifying questions that matter most.

Plus: There is a template included that you can use implement these techniques in your refinements 🎁.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Here’s a question that’s been bouncing around my head for some time:

Why do some teams ship ON TIME constantly, while others with similar talent and budgets struggle to get anything out the door?

I've been obsessed with this question because I recently witnessed two Agile teams in the same company: one that ships every week, and the other that is always "almost done."

Why?

The obvious answers don't hold up.

I’ve spent the last few months exploring this. I talked to the delivery leads at some of the most renowned companies in the world.

Here’s what I found.

Shipping (in most cases) is NOT an engineering problem.

It’s not.

The problem is “coordination” across various team functions. One such coordination problem exists between two roles that almost nobody thinks about: DevOps and Delivery Leads.

Today, I’m going to break down exactly how this relationship works, why most teams get it wrong, and what you can do to fix it.

Here’s what we’ll cover:

• The job of an Agile Delivery Lead

• The job of DevOps

• The coordination gap

• Mental models for better collaboration

• The framework that successful teams use to diagnose the problem

• What they do when production breaks

• The metrics they use

• An action plan that you can use for your team

Let’s get into it.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

And then there was Max.

Max was the Delivery Lead on a platform team I collaborated with many years ago. When I first joined the organization, people spoke about him with a kind of reverence that seemed excessive for someone in a coordination role. “You should talk to Max about that,” they’d say, or “Max would know how to handle this.” I thought it was just office shenanigans… someone who’d been around long enough to build a reputation.

Then I watched him work through a dependency crisis, and I understood.

What I’m sharing here is a series of lessons I learned from Max on Dependency Management. You won’t find these in a book. They’re practices I watched someone execute with remarkable effectiveness.

Let me tell you about this software release that started everything.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Marcus (an old friend) runs engineering at a Series B startup you’ve probably heard of. Smart guy. Former Google, Stanford MBA, the whole thing. Three months ago, he called me at 11 PM on a Tuesday.

“We’re failing every sprint,” he said. “Every single one. And my team is working nights and weekends.”

I’ve known Marcus for about five years. This wasn’t normal for him. He doesn’t panic.

“Tell me what’s happening.”

Marcus walked me through it. His team of eight had committed to 40 story points for the sprint. Reasonable number, he thought. They'd done 35 the previous sprint, and he'd hired another developer.

Two weeks later, they delivered 12 points. Half the work sat in testing. The other half wasn’t even finished. Stakeholders are furious. The team is exhausted.

“So we did a retro,” Marcus said. “Everyone agreed to work harder. We committed to 40 points again.”

I already knew how this ended.

Next sprint: 15 points delivered. Same pile-up in testing. Same exhaustion. Same fury.

“Marcus,” I said. “How many hours a day do you think your developers actually write code?”

Silence.

“Eight hours, right? That’s what we’re paying them for.”

I’d heard this before. I hear it constantly. And it’s the first place everything falls apart.

I brought in Satya…

Satya is a Delivery Lead I've worked with for years. She's helped rescue probably two dozen teams like Marcus's. When I explained the situation to her, she laughed.

“Let me guess,” she said. “He’s planning like people work eight hours a day on sprint work.”

“How’d you know?”

“Because everyone does. And they destroy their teams!”

Satya agreed to audit Marcus’s team for a week. What she found wasn’t surprising to her, but it shocked Marcus.

His developers spent their days like this:

• 45 minutes in standup and other events

• An hour in “quick” meetings that appeared on their calendars

• 30 minutes on email and Slack

• Another 30 minutes on administrative garbage—timesheets, expense reports, the performance review system that HR loved

• 15 minutes on bathroom breaks and grabbing coffee

• And the rest? Maybe five hours. On a good day. When nobody interrupted them with “just a quick question.”

“Your eight-hour day is a myth,” Satya told him. “You’re planning for capacity that doesn’t exist.”

Marcus did the math. If his team had 5 actual working hours instead of 8, he’d been overcommitting by 60%. Every single sprint.

But this was just the start.

The Number that Marcus wasn’t ready for

Even after Marcus recalculated using realistic hours, the team still failed to meet the next sprint's goals.

Satya wasn’t surprised this time either.

“Who’s your tester?” she asked.

“Just one person. Jen. But she’s great.”

“How many points can she test in a sprint?”

Marcus pulled up his tracking. Jen had never validated more than 10 points in a sprint. Ever.

“OK, so your developers can build 30 points of work,” Satya said slowly. “But Jen can only test 10.”

The silence on that call lasted maybe 20 seconds.

“We’ve been building work that can’t possibly get tested,” Marcus said.

“Right. Your team’s capacity isn’t 30 points. It’s 10. You’re only as fast as your slowest essential function.”

I watched Marcus process this. He’d hired another developer, thinking it would speed things up. Instead, it just created a bigger pile-up at testing. Jen was drowning. The developers were frustrated that their work sat untested. And Marcus kept wondering why “adding resources” made everything worse.

He asked the question I’d been waiting for.

“How do I explain this to my CEO?”

The conversation nobody wants to have

Marcus’s CEO wanted dates. Firm commitments. “When will feature X be done?”

After the testing revelation, Marcus couldn’t give those answers anymore. Or rather, he could, but he’d been wrong every time, and everyone knew it.

“You can’t keep making promises,” Satya told him. “You have to start talking probabilities.”

Marcus hated this advice. I could hear it in his voice when he repeated it to me.

“My CEO doesn’t want probabilities. He wants dates.”

“Then he wants lies,” I said. “Because that’s what you’ve been giving him.”

That landed harder than I meant it to.

Here’s what Satya taught Marcus to say instead: “Based on our velocity over the last six sprints, there’s an 85% chance we’ll complete this feature by the end of Q2. There’s a 50% chance we’ll have it by mid-April.”

The first time Marcus tried this with his CEO, the response was immediate.

“That’s not good enough. I need a commitment.”

“Then we can commit to the end of Q2,” Marcus said. “But you should know there’s a 15% chance we’ll miss it. We’ve never been more certain than that about any deadline.”

His CEO stared at him. Then asked a question Marcus hadn’t expected.

“What would it take to get to 95% certainty?”

It was at this moment that they had a real conversation.

• About tradeoffs

• About what could be cut or delayed

• About whether it was worth hiring a second tester

It was the first honest discussion of a roadmap they’d had in months.

But even with realistic capacity planning and probabilistic forecasting, Marcus still needed to see where the work was actually going.

Cumulative Flow

About six weeks into working with Satya, Marcus showed me something during one of our regular check-ins.

“Look at this,” he said, sharing his screen.

It was a chart with colored bands stacked on top of each other. The blue “In Testing” band kept getting wider and wider over time, like a snake that had swallowed something too large.

“This is a cumulative flow diagram,” he said. “Satya made me start tracking it.”

Now… I know what Cumulative Flow Charts are, but Marcus was looking at it like he’d discovered fire.

“You can literally watch the bottleneck happening in real-time,” he said. “Look… work enters testing here, but it barely leaves. It just piles up. This is why we kept failing sprints. It’s not that we weren’t working hard enough. The system was literally broken.”

The chart showed what Satya had told him weeks earlier. But seeing it visualized changed Marcus’s perspective.

“We showed this in our retro,” he continued. “Instead of everyone promising to work harder, we actually talked about the problem. We’re hiring a second tester. And we’re training two developers to do basic testing, so Jen isn’t the only one.”

That testing bottleneck had been strangling his team for six months. Six months of failed sprints and burnt out people. And the whole time, everyone thought the problem was effort.

The problem was never effort.

What Marcus's team looks like now

I talked to Marcus last week. His team has completed their last four sprints successfully. They’re delivering around 18 points per sprint now, less than half of what he used to commit to.

But they’re actually finishing what they commit to.

“Jim (his CEO) is happier than when we were promising 40 points and delivering 12,” Marcus said. “Turns out predictability beats optimism.”

His developers aren’t working weekends anymore. Jen isn’t drowning. And when Marcus gives a forecast now, stakeholders trust it.

He still struggles with the probabilistic language sometimes. His instinct is to give confident dates. But he’s learned that confident dates built on fantasy just create disasters you can predict.

Lesson for us?

Team’s capacity is not what we think it is…

What gets me about Marcus’s story is how common it is. I can’t tell you how many teams are right now planning sprints based on mythical 8-hour workdays, ignoring their bottlenecks, making promises they can’t keep, and wondering why they keep failing.

And the leaders running those teams… they’re not bad at their jobs. They’re just using a planning model that was broken from the start.

I know everyone’s going to say this is about tools and processes. Use the right estimation technique. Follow the events. Track the metrics.

But here’s what nobody wants to talk about.

The framework doesn’t work if leaders don’t actually want to hear the truth. Truth about capacity, what’s needed and what’s absolutely not needed.

The breakthrough in Marcus’s story wasn’t learning about cumulative flow diagrams. It was accepting that his team couldn’t do what he’d been asking them to do. That the capacity he wanted didn’t exist. That probabilistic forecasts were more honest than confident deadlines.

Most leaders don’t want to accept that. They want to believe that the right motivation or the right process will unlock more capacity. They want to believe that if the team just focused more or worked smarter, they could deliver those 40 points.

And as long as leaders believe that, the tools and frameworks are useless.

Satya put it well when I talked to her yesterday.

“Every team I rescue has the same problem,” she said. “Leadership planned for the team they wished they had, not the team that exists. And then they blamed the team when reality showed up.”

Marcus’s team is still the same people it was six months ago. Same skills. Same hours in the day. Same constraints.

The only thing that changed was that Marcus finally stopped planning for a team that didn’t exist.

Show your support

Every post on Winning Strategy takes a few days of research and 1 full day of writing. You can show your support with small gestures.

Liked this post? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone who would find this helpful? Make sure to recommend it.

I strongly advise that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.

Further Reading

1. How to Calculate Team Capacity for the Upcoming Sprint + Capacity Template

2. Scrum Team Capacity Template - Ver.2

3. Team Capacity Calculator v3.0

Connect With Me

• Connect on LinkedIn (I publish every Monday, Tuesday, Wednesday, Thursday and Friday)

• Connect on Community Chat

• Connect on YouTube

Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America’s largest banks.

Leave a comment

Q: Hi Vibhor, We’ve started using the Cursor tool extensively for development, and it has changed how work flows for the team. Because developers often work across multiple stories together in Cursor, a lot of progress tends to materialize toward the end of the sprint rather than story-by-story throughout. Given this shift, the team is questioning whether story-level estimation is still adding value. They feel estimating at the epic level and tracking progress based on who is contributing to an epic may be more meaningful than individual story estimates.

Thanks for the question.

Let me start by saying that your concern, or rather your team’s concern, is valid. Here, the technology layer (introducing Cursor) is forcing a change in the Process layer.

We have experienced this before AI, too.

Your team is experiencing "Context Contamination." Here’s how to understand this:

In non-AI development, we split user stories vertically to keep cognitive load manageable. In AI development, developers feed AI with large context (multiple files, whole modules) and implement changes that span multiple stories because the “AI understands the whole feature set” … as they say!

As a result…

The "Vertical Slice" (finishing one story completely) is being replaced by "Horizontal Batching" (coding three stories at once, then testing them all at once in the end).

Your team’s pain is:

If AI reduces the coding effort of a complex story from 3 days to 3 hours, the relative difference between a "3-pointer" and a "5-pointer" becomes negligible. Implementation is almost instant. So spending 30 minutes in Refinement debating points seems like a waste of time.

Your team’s proposed solution is:

Estimate epics + track who contributes per epic

Does this solution make sense?

Let’s find out.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

As Agile Delivery Leads, things change… just a little bit.

You still have those Scrum Master goals, BUT those goals are layered with 3 additional responsibilities:

1. delivery assurance,

2. risk management, and

3. strategic alignment

Note: Remember these three points. I'll mention them every time I discuss Agile Delivery Leads.

Here's a simple Sprint Planning structure that you, as an Agile Delivery Lead, can confidently run on a regular basis, with clear responsibilities to guide you.

Let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

What you missed in the last few weeks

1. How to handle paused work in Scrum

2. 8 conversations to have with your new team in the first 30 days

3. Quarterly release report for your VP

4. How to motivate your team?

5. My Advice for Scrum Masters to Get a New Role Faster

6. From Servant Leader to an Agile Delivery Lead

7. Agile Delivery Lead and the Sprint Goal

Read more

Take the example of a Sprint Goal.

Sprint Goal changes from being something you facilitated to being something you will use as leverage.

It is no longer a Scrum artifact that lives in Sprint Planning and gets referenced in the Daily Scrum.

No!

It is a delivery alignment mechanism. You use it to make sure delivery happens… on time!

Sprint Goal will help you navigate across product and engineering, manage dependencies, and keep stakeholders focused on what matters.

In the rest of this post, I’ll unpack how to use the Sprint Goal with a delivery-leader mindset to guide your decisions.

There’s a lot to cover, so let’s get started.

Got an urgent question?

Get a quick answer by joining the subscriber chat below.

Read more

Q: Hi Vibhor, Do you suggest any Initiative/Release report that we can share periodically to the VP /Product side leaders? If yes, is there any template or content you suggest ?

Thank you for the question and for giving me a chance to turn your chat comment into something useful.

I don’t have the exact, one-size-fits-all status template you asked for.

But…

What I do have is a pile of notes gathered from seeing such reports and watching which fields and sections, and what kind of information, make execs lean forward for more.

Using those notes, I have created a template for you that you can use as inspiration.

Note: The template is Notion-based because I find it easy to use. You can use any spreadsheet based tool you like.

Got an urgent question like the one asked in this post?

Get a quick answer by joining the subscriber chat below.

Read more