Pulse Framework: get started

4 steps to put your dev process on metrics and find the phase that is broken

The Pulse Framework describes what a working dev process looks like. This page is how you measure yours against it.

4 steps: agree with the team on the rhythm you want, pull the numbers out of the tools you already run, find the phase that's broken, then keep it honest month to month. By the end you have 1 list. Every phase of your process gets 2 lines: where it stands today, and what you do about it next, with a name and a date on it. Filled in, it looks like this:

Plan. 0.5 sprints of estimated work ready, tasks estimated in weeks. Break every task over 40 hours into pieces of 16 to 24 hours and get the backlog 2 sprints deep. Anna, next sprint

Design. Build waits 4 days for a designer on every feature. Whoever writes the task builds the clickable prototype in v0 or Claude Code and puts it on the task before Build starts. Anna, 1 month

Build. 4 commits last month, 3 weeks with none at all. Cut tasks down until every dev can push something every working day, and check it at the weekly 15 minutes. Mark, 2 months

Test. Median merge time 31 hours, 0.4 review comments per PR. Automated review on every PR, a named reviewer on each one, merge time under 24 hours. Mark, 2 months

Release. Further discovery needed: releases land every 3 to 5 weeks, and nobody has traced where the weeks go. Walk 1 released task through review, testing and deploy with the team, then pick the fix. Mark, 2 weeks

Operate. 6 of 9 bugs last month came from customers. Sentry on all production errors, alerts into the channel the team already reads. Lena, 2 weeks

Every number in it comes out of a tool you already run. None of it is a guess, and none of it is typed in by hand. Where you have no number yet, write "further discovery needed" and the action that gets you one, the way the Release line does.

Fill it in as you read: download the spreadsheet and open it in Google Sheets. 1 tab per step, every list and table on this page already in it.

🚀

Step 1 is a conversation with your team. Steps 2 and 3 need admin access to your task tracker and read access to your repo, and take about a day. Step 4 is what you keep doing afterwards. Do them in order, they build on each other.

1. Set the rhythm you're aiming for

Before you measure anything, agree with the team on what the process should look like. It comes down to 4 rituals. Each one forces work to finish instead of piling up.

Daily commits. Every dev pushes something every working day. A day without a commit means the task is too big or the person is blocked, and both need to surface that day, not at the demo

Daily updates. Written in Slack by the person who did the work: what moved, what got published, what's blocked. A status call doesn't count, nobody can read it later

Weekly releases. A fixed day of the week. Whatever is ready goes to production, the rest waits for next week. The date does the forcing, not the scope

Steady backlog. 2 sprints of work ready at any moment, estimated in hours and tagged feature, improvement or bug, so nobody picks the next task at random

Then 3 things stop being somebody's job:

Testing code. Automated tests on the core flows and automated review on every PR, so a human review is about design and not typos

Customer issues. Production errors reach you from monitoring before a customer writes in. A question that comes twice becomes a help center article

Feature prototyping. A clickable prototype on the task before Build starts, built by whoever wrote the task in v0 or Claude Code, instead of waiting in a designer's queue

The whole team runs all 4, every week, without anyone chasing it. Step 2 turns each one into a number, and a ritual you only say you run shows up as a flat line.

2. Collect metrics on each phase

1 or 2 numbers per phase, and each one answers whether a ritual from step 1 actually happens. Only take numbers a tool produces on its own. Anything a person types by hand stops in 2 weeks.

Phase	Metric	Pull it from
Plan	Estimated and assigned tasks sitting in Backlog and Sprint	Saved tracker view
Design	Prototypes handed to devs per week	Links posted on the task in Figma or v0
Build	Commits, pull requests opened and written updates posted per week	GitHub Insights, Slack
Test	Median open-to-merge time, review comments per PR, test coverage	GitHub pull request list, CI
Release	Deploys per week, tasks moved to Released	Deploy log, tracker
Operate	Production errors per week, support messages per week	Sentry, support inbox

Chart everything by month, 6 months back. A single week is noise. This is the Build and Test set in Pulse :

Tasks done , split into feature, improvement and bug. A month with no features went into bugs

Commits pushed . Pace only. Big and small commits count the same

Median merge time . The wait between "the code is written" and "the code is in"

Review activity , comments and approvals per merged PR

3. Find what's broken and set a target

Go phase by phase and put your numbers next to the table below. Every line you hit is a broken phase. Write it into your list with your own number attached and take the action on the right. Put a name and a date on every line you write.

Phase	What you see	What it means	Target
Plan	Less than 2 sprints of estimated work ready	Backlog runs dry, devs pick work at random	2 sprints ready at any moment
Plan	Any task estimated over 40 hours	The task isn't broken down and it will slip	No task over 40 hours
Design	Build can't start until a designer frees up	Design is a queue of 1 person	A prototype on the task before Build starts
Build	Fewer commits in a week than working days	Tasks are too big to finish in a day, and nobody sees it until the demo	A commit from every dev every working day
Build	Commits cluster in the 2 days before a demo	Work starts late and review time gets squeezed	The same commit pace every week
Build	Fewer written updates in a week than working days	Progress lives in someone's head and blockers surface at the demo	1 written update per dev per day
Test	Core flows have no automated test	Every release is a manual regression pass, so releases get rarer	Automated tests on the core flows
Test	Median merge time over 24 hours	PRs sit, and the author has moved on by the time review lands	Median merge time under 24 hours
Test	Under 1 review comment per PR	Nobody reads the code, approval is a rubber stamp	A comment or approval from a named reviewer on every PR
Release	Releases land on no fixed day	Nothing forces work to finish	1 release to production every week
Operate	Customers report bugs before monitoring does	You learn about production from your users	Sentry on all production errors

Most teams hit 4 or 5 of these on the first pass. Fix them in phase order, not in the order they annoy you: a broken Plan phase produces broken Build numbers, and fixing Build first changes nothing.

4. Monitor monthly, check in weekly

A number changes how people work only if somebody looks at it on a schedule.

Weekly, 15 minutes, the same slot. You check the rituals, not the targets. 4 questions:

Did every dev commit on every working day?

Did the written updates go out?

Did the release land on its day?

Is the backlog still 2 sprints deep?

Anything answered no gets fixed that week, while it is 1 week of damage and not a quarter of it.

Monthly, with the charts open. You check the targets. Pull the same 6 months of history, write the new numbers into your list, and mark every line hit or missed. A target missed twice is either wrong or has no real owner. Change the target or change the owner, but don't let it sit.

The monthly review is also where the list at the top of this page gets rewritten. Phases that hit their target drop off it, and what's left is next month's work.

Want us to do all 4 steps on your project? Book a call and bring your tracker and your repo.