A Project Management Playbook for Software Development Teams

A team that could describe its work, but not measure it

Take a software development team of around twenty people, split into three or four squads, building a product used by other departments in the same company. They ran two-week sprints, had a backlog, held stand-ups, did the things a development team is supposed to do. The engineering lead could describe what the team was working on in real detail. What was harder was answering a specific question: how long does a ticket actually take, on average, from the moment someone starts it to the moment it ships.

Nobody was hiding that number. It simply didn't exist anywhere. Cycle time would have meant someone manually timestamping when a branch was created and when the pull request merged, across every repository, every squad, every week, and reconciling it against a separate task tracker that had no idea a pull request had even happened. Nobody had the hours for that, so the team ran on feel: "that felt like a fast sprint" or "reviews have been slow lately," true impressions that never got tested against anything.

The board itself was a second problem sitting on top of the first. Cards moved because someone remembered to drag them, which meant the board's picture of reality was only as current as the last person who'd bothered to update it, usually right before stand-up, not continuously as the actual work happened.

Before: a burndown chart that lagged the code by a day

The gap between what the board showed and what was actually true in the repository caused real friction. A card would sit in "in progress" for four days after the pull request had already merged, because updating the board was a separate, forgettable step from the work of shipping code. Sprint reviews spent real time just reconciling the board with reality before anyone could talk about what actually happened.

Sprint planning had a related problem. Without real cycle-time data, estimates were built on gut feel that varied by squad and by mood. One squad consistently overcommitted and burned out trying to hit a plan built on optimism; another consistently undercommitted and looked slower than it was. Nobody had the data to tell which squad was calibrated and which wasn't, so the conversation stayed subjective, and subjective conversations about performance rarely go well.

And when a sprint was genuinely going to miss its goal, the team usually found out on the last day, in the sprint review, rather than with enough runway to actually adjust scope or ask for help.

After: sprint reviews about the work, not about the board

The most immediate change was in the sprint review itself. Reconciling the board with the repository used to eat the first fifteen minutes of every review. With the board updating itself from branch and merge activity, that time went back to actually discussing what shipped and what didn't.

Cycle time stopped being a feeling and started being a number each squad could track over its own history. That mattered more for calibration than for comparison: a squad could see whether its own reviews were getting faster or slower over successive sprints, without turning it into a league table between squads doing genuinely different kinds of work. And a forecast that moved with the sprint, instead of sitting fixed from the planning meeting, meant a squad heading for a miss had days of runway to descope or ask for help, instead of finding out at the review.