Day 12 — From Building to Managing: My First Real AI Sprint

Today was a shift.

Up until now, I’ve been focused on getting things working — setting up OpenClaw, wiring up my environment, building out my first Dynamics web resources, and troubleshooting all the little things that break along the way.

But today, I took a step back and realized something:

If I want to transition into Product Management, I can’t just build — I need to start running this like a product team.

Moving Into Agile (For Real This Time)

I’ve read about Agile. I’ve been around it. I’ve even participated in parts of it before.

But this is the first time I’ve actually owned the process end-to-end.

I decided to start breaking my work into simulated sprints, using Azure DevOps as my control plane and OpenClaw as my “AI developer.”

That meant:

  • Defining a Sprint Goal
  • Creating User Stories
  • Breaking those into atomic tasks
  • Assigning work into an iteration
  • Estimating using story points
  • And most importantly — controlling execution

Designing a Sprint Planning System

Instead of jumping straight into development, I created a dedicated Sprint Planning workflow.

I built out a reusable template that includes:

  • Sprint context
  • A clear, outcome-focused goal
  • Candidate backlog items
  • Committed scope
  • Story points
  • Execution order (critical for AI)
  • Risks and unknowns
  • Definition of done
  • And something new — AI execution instructions

That last piece turned out to be the most important.

The Realization: AI Needs Constraints, Not Just Prompts

Up until now, I was treating OpenClaw like a smart assistant:

  • Give it a task
  • Let it plan
  • Let it execute

But that approach breaks down fast when you're trying to simulate a real development environment.

So I introduced a new concept into my user stories:

Execution Instructions

These act like guardrails for the AI:

  • Work one task at a time
  • Do not implement the full solution in one pass
  • Explain the approach before coding
  • Confirm completion after each task
  • Do not move ahead without finishing the current step

What I’m effectively doing is turning Azure DevOps into:

A task queue for an autonomous developer

Structuring the Backlog

For my first sprint, I focused on a single vertical slice:

Capacity Forecaster → Storage Usage

Instead of trying to build everything, I broke it down into:

  • Retrieve Dataverse storage usage
  • Abstract data into a service layer
  • Load data on initialization
  • Render it in the UI
  • Handle errors

Each of these became separate tasks, intentionally small and sequential.

The idea was simple:

Don’t let the AI think — let it execute.

First Execution… and First Lesson

I kicked off the pipeline on the first task:

“Identify correct Dataverse endpoint”

What I expected:

  • Some notes
  • Possibly a test query
  • Basic exploration

What I got instead:

A fully built, production-ready service layer:

  • API call implemented
  • Data conversion helpers
  • Error handling
  • Logging
  • Reusable global service

Technically, it was great.

Process-wise, it completely ignored the task boundaries.

The Key Learning

This was the biggest takeaway of the day:

AI will always try to solve the entire problem unless you explicitly prevent it.

Even with instructions like “do one task at a time,” it still jumped ahead.

That told me something important:

My system wasn’t strict enough yet.

Adjusting the System

Going forward, I need to tighten control by:

  • Making tasks even more explicit and atomic
  • Adding stricter execution rules (no future work, no assumptions)
  • Enforcing validation before moving to the next task
  • Treating tasks as hard execution boundaries, not suggestions

This is no longer just about writing code.

It’s about:

Designing a system that controls how code gets written

Something Else Happened

For the first time, I actually felt like I was:

  • Planning work
  • Sequencing dependencies
  • Managing execution
  • Validating outputs

Not just building.

That’s when it clicked:

This is what Product Management actually feels like.

Where This Is Going

Right now, I’m still early.

But I now have:

  • A working UI inside Dynamics
  • A structured sprint system
  • A backlog in Azure DevOps
  • An AI developer executing tasks
  • And a feedback loop to improve the system

Next up:

  • Enforce task-level discipline
  • Validate real data retrieval
  • Continue building out the console one slice at a time

Final Thought

Today wasn’t about shipping a feature.

It was about learning how to:

Run development, not just do development

And that feels like a much bigger step.

More tomorrow.