Pulse: Software Development Without Sprints

Part 2 of the Post-Scrum series

Part 1 made the case that Scrum's ceremonies lose their justification when AI makes implementation cheap. That doesn't mean you tear them down overnight. What happens in practice is subtler: sprints start feeling rigid, refinement stretches longer than the tasks it clarifies. The ceremonies thin out on their own. The question is what takes their place.

Sprints gave teams two things beyond rituals. Predictability: business knew roughly when things would ship. Breathing room: if you finished early, you had slack for fixes, experiments, or just catching your breath. Continuous flow without any boundaries loses both. Business has no delivery horizon, the work never ends, and people burn out.

You need a structure that fits the new economics. Not another set of ceremonies, but something that preserves predictability and rest while dropping the overhead. That's what Pulse is: a pull-based workflow with a cadence of three weeks of flow, one week of breathing.

The Pull-Based Development Workflow

If Scrum defines the development lifecycle through sprints, planning, and ceremonies, what does the lifecycle look like without them? The model below covers the cycle of how work flows when you remove batch processing and let developers take tasks continuously.

• Business defines WHAT and WHY
• Product Owner prepares and hands developer a task
• Developer implements (with AI)
• Automated tests (CI/CD)
• Code review (focus: architecture, data model, security)
• Ship (continuous delivery)
• Retrospective (the only ceremony)

No sprints, no estimation, no refinement. Tests are the safety net, and the retrospective is the only ritual that stays.

Part 1 covered why input quality determines everything: the Product Owner, assisted by AI, prepares business-level task descriptions before a developer ever touches the work. Everything below focuses on what happens after the developer receives the task.

The Product Developer's Workflow

In this model, the developer is no longer a frontend or backend specialist. One person takes a task and delivers it end to end, through the full stack, with AI filling the knowledge gaps. Part 3 covers the role in depth. Here, what matters is the workflow.

The developer's work on each task follows three phases: research, plan, implement. In the research phase, AI analyzes the codebase to understand existing patterns and where the change fits. The developer then creates a plan: what to change, how, and in what order. AI drafts it, the developer iterates until the approach holds up. Implementation follows the plan, with AI writing the code and the developer reviewing each step.

The developer is accountable for the output. AI generates, the developer verifies. For a detailed walkthrough of this workflow, see From Vibes to Process: AI Coding in Production Codebases.

Pulse: Cadence Without Batch

The workflow above covers how tasks move from business to production, but it says nothing about pace. Without cadence, continuous flow becomes a treadmill: the developer delivers, takes the next task, delivers again. The work never ends, and there's no natural pause for retrospectives, process improvements, or recovery.

Defining Pulse

Everything above, the pull-based workflow, the product developer delivering end to end, continuous delivery with throughput forecasting instead of estimation, is the operational model. Pulse is the name for this model, combined with a cadence that prevents it from becoming a treadmill: three weeks of flow, one week of breathing.

During the three flow weeks, the team operates in continuous delivery mode. Get a task, implement, ship, repeat. During the breathing week, the team steps back for retrospective, tech debt, process improvements, and learning.

Why Three Weeks of Flow, One Week of Rest

The ratio is intuitive, not scientific. But there are good reasons behind it:

• Six weeks (like Shape Up) is too long. You don't remember the context from deliveries at the start of the cycle. You can't do a meaningful retrospective when half the work happened six weeks ago.
• One day of rest (like 4/1 in days) is too little. It creates pressure rather than relief.
• Three weeks is close enough that you can still think back to what you delivered at the start of the cycle.
• One week is enough without feeling disconnected from the fast pace of delivery.
• 3+1 is roughly a month. Repeatable. Easy to remember. Aligns with natural cycles (billing, reports, vacations).

The breathing week isn't vacation. It's time for things that have no place in continuous flow, but without which the team degrades over time.

Why Pulse and Not Kanban, Shape Up, or SAFe

Each of these frameworks solves part of the problem, but none fits AI-assisted development fully.

Kanban

Kanban gives you continuous flow and a pull system. That's exactly what Pulse uses for the flow weeks. But Kanban has no built-in rest mechanism. It has "cadences" (rhythmic sync meetings), but no structural rest. At the new pace of work, if you don't build in rest systemically, people burn out.

Shape Up

Shape Up has cooldown (two weeks after six-week cycles), which is the right instinct. But Shape Up is team-oriented. The entire team works together through a cycle on one project. Pulse is built around individual developers working autonomously. A product developer takes a task and delivers end to end, without waiting for a team cycle to start or end.

SAFe

SAFe goes even further in the team direction. Agile Release Train (8-12 teams), Program Increment (10-12 weeks), PI Planning as a massive synchronization ceremony. The entire framework is built around coordinating large groups. Pulse goes in the opposite direction: minimizing coordination, maximizing individual autonomy.

What Pulse Takes From Each

Pulse takes from Kanban the continuous flow and pull system. From Shape Up, the built-in rest. From the #NoEstimates movement, throughput forecasting.

But it orients everything around the individual product developer, not the team as the unit of work.

The ideas aren't new, just assembled into something that fits AI-assisted development.

Throughput Forecasting Instead of Estimation

Scrum estimates how long each task will take, then plans a sprint around those estimates. Throughput forecasting works in the opposite direction: you observe how many tasks the team delivers per week, assume the pace holds (no major process blocks), and use that to predict when queued work will ship. You don't estimate individual tasks. You prioritize the queue and let observed pace do the forecasting.

This is conceptually close to velocity, but without the ceremony. No story points, no planning poker, no sprint commitment. Just a running average of delivered tasks and a prioritized queue. If the team delivers eight tasks per week and the queue has twenty-four items, the business knows roughly when the last one ships. When the pace changes, the forecast updates automatically.

Three metrics give you the full picture:

• Lead time: time from business describing the task to production deploy. This is the metric that matters most. It measures what business actually feels. Not "how many tasks did we complete" but "how fast does a business idea become reality."
• Features described by business (measures input). If this number is low, throughput will not help. Nothing to deliver. This metric exposes the bottleneck on the business side.
• Features delivered to production (measures output). Comparison with input shows where things stand: in queue, in implementation, in review, in deploy.

These three together replace velocity charts and burndowns.

Transitioning to Pulse

You can't jump from "we don't use LLMs" to Pulse overnight. The transition has stages, and the dependencies between them are hard.

A necessary condition: a technical leader (CTO, Head of Engineering) who is ahead of the team, not catching up. Someone who knows the tools, understands the process, and sees where the transformation bottleneck is. At every stage, their role is different.

Developers Learn to Work With AI

Scrum stays as is. The only change: developers start using AI in daily work. They learn to evaluate output, calibrate prompts, understand when the AI is wrong. This takes months. The leader chooses tools, sets initial standards, and teaches by example. Knowledge-sharing sessions, live demos of their own workflow, hands-on guidance.

The Workflow Formalizes

Developers work effectively with AI. You formalize the workflow: research, plan, implement. Tasks start taking days rather than weeks. Scrum starts grinding: refinement feels too long, estimates feel heavy, the sprint is too rigid.

But you don't throw Scrum out yet. The product owner can't work with AI. Business doesn't prepare tasks differently. You have no throughput data. Start loosening: simplify estimates (S/M/L rather than story points), shorten refinement, do sprint review weekly rather than bi-weekly.

The Product Owner Works With AI

The hardest step, and probably the most important. The product owner must learn to work with AI: break down epics, clarify requirements, answer questions about edge cases. A new competency that takes time.

Only when the product owner can do this can you drop refinement as a ceremony. Before that, refinement was the only moment to extract precision from the product owner. The leader's role here is to be the bridge: sit down with the PO, show how AI can help prepare tasks, what questions to ask, how to break down an epic. Without someone who walks the PO through this change, you end up with a ready team and unprepared input.

As this takes hold, throughput data accumulates naturally. You start to know how many tasks the team completes per week. Estimates drop because you have something better: observed pace. Sprint planning loses meaning. Continuous flow plus throughput gives predictability without ceremony.

Full Pulse

All pieces in place. Continuous flow with built-in rest, continuous delivery, retrospective every breathing week, planning at the epic level.

Stages Overlap

In practice, these stages overlap. A developer might be in stage 1, the product owner starting stage 3, the team still in Scrum but loosening. That is normal.

But the dependencies are hard. You can't jump to Pulse without throughput data, can't drop refinement without the product owner working with AI, and can't formalize the workflow without developers who work with AI effectively. At every transition, the technical leader must be one step ahead.

Not every team will reach stage 4. Some will stop at 2 or 3, and that's fine. A lighter Scrum with AI-assisted workflow is already a significant improvement. Pulse is for teams that have the conditions: seniority, trust, good tests, a capable product owner. And a leader who guides through the change.

Pulse as a Starting Point

Pulse assembles proven components (Kanban flow, Shape Up breathing, throughput forecasting) around the reality that AI changed the cost equation of software development. A starting point, not a dogma. Teams should calibrate in retrospectives and adapt to their context.

Part 3 of this series covers who fills the roles in this new model.

Articles in this series

• Why Scrum Stops Working in the AI Era
• Pulse: Software Development Without Sprints
• Product-Centered Team for the AI Era