Sprinting forward

You’ve got a team. You’ve got a roadmap. You’ve been given the speech.

“This is a strategic priority.”
“Leadership is fully behind this.”
“This is going to be huge for the business.”

Everyone’s nodding, whiteboards are filling up, and the room smells like fresh markers and optimism.

Then we sit down to plan Sprint 1.

Suddenly, the vibe shifts.

Stakeholder: “So we can knock out user registration, the core workflow, and the first three integrations in the first sprint, right?”

Team: “No. Not even close.”

Stakeholder: “But… we promised it. It has to get done.”

And just like that, the fantasy collides with physics.

---

I’ve worn both hats: senior product owner and scrum master with a technical background. My job, over and over, is to stand in the gap between what we wish were true and what is actually possible in two weeks with five humans and a creaky legacy system.

That moment—right before Sprint 1—is where most teams quietly screw themselves for the next 6–12 months.

Not because the vision is wrong.

Because the expectations are.

The Real Job in Sprint 1

Sprint 1 is not “do everything we promised.”
Sprint 1 is prove we can deliver something valuable in a repeatable way.

As a product owner, I care about outcomes and sequencing. As a scrum master, I care about flow and system health. As someone technical, I know exactly how much invisible work gets hand-waved away when someone says, “It’s just a simple feature.”

So I treat Sprint 1 as a calibration exercise, not a hero sprint.

My goals for Sprint 1 usually look like this:

• Establish a real Definition of Done (including testing, not just “it runs on my machine”).
• Ship at least one thin vertical slice that a real user could, in theory, touch.
• Get a realistic sense of team capacity based on actual data, not wishful thinking.
• Expose the first batch of technical unknowns early, when they’re still cheap.

If we do that, Sprint 2 and Sprint 3 become dramatically saner.

Pushing Back Without Being a Jerk

When someone says, “We need all this in Sprint 1,” they’re not usually being malicious. They’re scared. They’re trying to de-risk their world by pretending uncertainty doesn’t exist.

My playbook:

1. Anchor on time, not fantasy.
   “We have 10 working days and 5 people. That’s 50 person-days. Now let’s subtract meetings, support, onboarding, and context switching. Realistically we’ve got maybe 30–35 productive days. What do you want to buy with those days?”

2. Translate features into trade-offs.
   “We can try to do all three integrations, but that means no automated tests and no time to fix what we inevitably break. Is that a trade-off you want to make?”

3. Use Sprint 1 as an experiment.
   “Let’s treat this sprint as a test of our assumptions about how fast we can move. We’ll plan for X, measure what we actually deliver, and adjust the roadmap based on reality—not feelings.”

4. Refocus on a Sprint Goal.
   “Instead of ‘do everything,’ how about: By the end of this sprint, a user can sign up and complete one core workflow end-to-end. Everything else is optional.”

You’re not saying “no” for fun. You’re saying “no” so the team can deliver a real “yes” later.

What Sprinting Forward Really Looks Like

Sprinting forward doesn’t mean sprinting faster. It means sprinting smarter:

• You ruthlessly slice work so value shows up early.
• You protect the team from being turned into a feature factory on Day 1.
• You accept that Sprint 1 is going to expose ugly truths about your architecture, your data, your dependencies.

And you use those truths.

Because nothing kills a product faster than pretending the first sprint is a magical exception where all constraints disappear.

So yes, enjoy the kickoff hype. Let people dream big. Then, when you sit down for that first sprint planning and someone says, “We promised it all,” you take a breath and do your real job:

Bring the ambition down to a level the team can actually deliver.

That’s not lowering the bar.

That’s how you make sure the damn thing ships.