Project Management for Scrum Projects

Scrum's vocabulary, taken literally

A lot of "Scrum support" in project tools amounts to a board with a column called "Sprint" and a burndown chart nobody checks. The words are there; the mechanism that was supposed to justify them usually isn't. A product backlog that isn't actually groomed before it hits a sprint. A sprint commitment that isn't checked against what the team has actually delivered before. A review that happens whether or not there's anything real to show.

ShipSprint takes the terms literally rather than decoratively. Each one maps to something the board actually enforces, not just a label someone applied to a column. Run a real sprint here and the WIP limit you set at commitment is still holding on day nine, and the forecast is already telling you Thursday's outcome by Tuesday.

The mapping, term by term

Product backlog. Everything that hasn't been committed to a sprint yet lives in one place, fed by a triage inbox rather than scattered across messages and memory. Grooming it is sorting a real queue, not reconstructing one from scratch each time.

Sprint commitment. What a team takes on is checked against its own measured velocity from previous sprints, not against what the roadmap wishes were true. Committing to more than the number supports is a visible decision, not an invisible one.

Sprint backlog. Once committed, the column carries a WIP limit that holds for the length of the sprint. The backlog can't quietly grow past what was agreed on day one, because the board itself won't let it.

Daily scrum. Every person opens to a "my day" screen: today's items, a one-tap time log, one tap to flag being blocked. The stand-up can be about what actually changed since yesterday, because the status itself doesn't need reciting.

Sprint review. The forecast for the sprint, built from measured velocity as work completes, is visible before the review happens, so the review can be about the work itself rather than a surprise reveal of whether the sprint made it.

A sprint, start to finish

Monday morning, the product backlog has been groomed against last sprint's actual output, so the sprint commitment isn't a debate. It's fifteen items that fit inside a capacity number nobody had to argue for. The sprint backlog fills up, its WIP limit set at the same number the team committed to, and stays there for the length of the sprint because the board doesn't let it drift.

Through the week, the daily scrum runs off the "my day" screen each person already has open (today's items, whether anything's blocked), so the fifteen minutes go to what actually changed rather than a status report everyone could have read themselves. Wednesday, someone hits a dependency they can't resolve alone; one tap flags it as blocked, and the right person is pulled in with the context already attached instead of a message that starts with "hey, quick question."

By Friday of the second week, the forecast has already told the team, days in advance, whether they're on pace, so the sprint review isn't the first moment anyone learns the sprint came up short. What's left to discuss in the review is the work itself, and what's left for the retro is genuinely about how the sprint felt to run, not a scramble to reconstruct what happened.

Scrum outside engineering

Scrum's vocabulary got invented for software, but the mechanism underneath it (a groomed backlog, a capacity-checked commitment, a fixed-length sprint with a review at the end) isn't specific to writing code. An HR team running a hiring sprint, or an ops team clearing a backlog of vendor renewals, can run the identical structure: triage inbox feeding the backlog, sprint commitment checked against their own measured velocity, WIP limit on the sprint backlog holding for the length of the sprint.

What changes is only the vocabulary painted on top and the templates each team works from. Engineering, HR, marketing and operations each get their own on the same subscription. The scrum master facilitating a recruiting sprint and the one facilitating an engineering sprint are running the same underlying discipline, even though almost nothing about their day-to-day work overlaps.

What ShipSprint doesn't decide for you

It doesn't assign the roles. Who acts as product owner or who facilitates the scrum is a matter of permissions and habit, not a fixed account type the software imposes on your org chart. It doesn't run the ceremonies for you either: planning, the daily scrum, the review, the retro are still meetings your team holds. What changes is that each one walks in with real numbers instead of a status update someone had to go collect first.

Velocity that doesn't require a particular estimation ritual

A lot of Scrum implementations get stuck arguing about estimation before they've shipped anything: story points versus t-shirt sizes versus hours, planning poker versus a facilitator's gut call. ShipSprint's velocity number doesn't require picking a side in that argument. It's built from what the team actually completed, sprint over sprint, whatever unit or method was used to size the work going in.

That matters practically because teams change estimation techniques more often than they admit, usually after a sprint goes badly and someone decides the sizing was the problem. The capacity number the next sprint gets planned against keeps working through that change, because it was never dependent on the technique to begin with. It's a count of completed throughput, not a reconciliation of estimated points against actual points.

The same logic extends across an organization running Scrum in more than one place. A marketing team and an engineering team can each use whatever sizing convention suits their work, and each still gets a real, team-specific capacity number to plan its own sprint commitment against, without needing to agree with the other team on what a "point" means.

Signs the mapping is actually working

• The product backlog is a real, groomed list, not a stale board section nobody has opened this month
• Sprint commitment is a number checked against recent velocity, not a target picked in advance
• The sprint backlog's WIP limit hasn't been quietly raised mid-sprint to fit in one more thing
• The daily scrum is fifteen minutes about changes, not a recitation of status that already exists on-screen
• The sprint review outcome was already visible in the forecast, so nothing in it is a surprise