Scrum framework
Scrum breaks work into short, fixed sprints with daily check-ins and a review at the end, so teams ship something working every few weeks instead of promising a finished product months away.
Arrows carry the team round from planning through daily check-ins to a review and reflection point.
Reach for this when…
- A project has been 'nearly done' for three months running.
- Requirements keep changing after the team has already committed to a spec.
- Stakeholders only find out something's wrong when it's too late to fix cheaply.
How to run it
- Build and order a product backlog, with the Product Owner ranking by value.
- Plan a sprint: pick backlog items the team can realistically finish in the timebox.
- Hold a daily scrum: what's done, what's next, what's blocking.
- Review the working increment with stakeholders at sprint end.
- Run a retrospective on how the team worked, and change one thing.
- Repeat the cycle with the next sprint.
A worked example
Situation. Nikola Jovanovic's SaaS company Sava Metrics, based in Belgrade, Serbia, had been 'nearly ready to launch' for four months with no working product to show a single customer.
Applied. He forced the team into two-week sprints, cut the backlog to what could genuinely ship, and made every sprint end with something a customer could actually click on.
Result. Three sprints in, they had a working beta in front of five customers, and the retrospectives surfaced the real blocker: a dependency nobody had flagged in four months of 'nearly ready.'
The catch
Scrum manages the process, not the product decision - a team can run perfect sprints and still build the wrong thing if the Product Owner ranks the backlog badly. It also assumes a stable, dedicated team; bolt it onto a team pulled in three directions and the ceremonies become theatre.
If your 'sprint review' is a slide deck instead of working software, you're not doing Scrum, you're doing meetings in two-week boxes.
Origin: Ken Schwaber; Jeff Sutherland