Scrum is a framework for organizing a small team’s work into fixed-length cycles, called sprints, each of which is meant to produce a usable increment of the product. It defines a few roles, a few recurring meetings and a few shared artifacts, and leaves most other practices to the team. Scrum is the most widely recognized way of putting Agile ideas into practice in software development, and many development partners and implementation firms structure their engagements and invoices around it.
At a glance
- Work happens in sprints of the same length, typically one to four weeks.
- Three roles: someone who owns priorities, someone who keeps the process working, and the people who build.
- Recurring meetings cover planning, a short daily check-in, a review of what was built and a look back at how the team worked.
- A prioritized list of remaining work, the backlog, is the single source of what’s next.
- For buyers, Scrum shapes staffing, billing, reporting and who has to make decisions on your side.
What problem it solves
Teams building something new often struggle with two problems: they try to plan everything far ahead and the plan goes stale, or they plan nothing and lose track of what matters. Stakeholders, meanwhile, can’t see progress until something is finished.
Scrum gives a light structure between those extremes. Committing to a short, fixed cycle forces regular decisions about what is most important now. Showing finished work at the end of each cycle gives stakeholders a predictable moment to see progress and change direction. And a short, regular review of how the team worked gives it a habit of fixing its own problems rather than repeating them.
How it works
Roles, in plain terms.
- The product owner orders and manages the product backlog, deciding what gets built and in what order, and clarifies the outcomes the business and users want.
- The Scrum master is a facilitator and coach who helps the team follow the process, removes obstacles and protects the team from distractions. It is not a traditional project manager role, though in vendor engagements it is sometimes combined with one.
- The developers are everyone who does the building and testing: programmers, testers, designers and others. They decide how to do the work and how much they can take on in a sprint.
Contractual acceptance of delivered work is a separate question: who holds that authority varies by engagement and is set in the statement of work (SOW), not by the Scrum roles.
The sprint cycle.
- Sprint planning. At the start, the team picks the highest-priority items it can realistically finish and agrees on a goal for the sprint.
- Daily check-in. A short daily meeting, often called the daily stand-up, where the team coordinates and flags anything blocking progress.
- Sprint review. At the end, the team shows what it built to stakeholders, gathers feedback and updates the backlog.
- Retrospective. The team discusses what went well and what to change about how it works.
Artifacts. The product backlog holds the known remaining work in priority order. The sprint backlog is the slice chosen for the current sprint. The increment is the finished, tested work produced. Teams usually agree a “definition of done” that sets the quality bar for counting work as finished, such as tested, reviewed and documented.
Many Scrum teams pair this rhythm with automated testing and CI/CD, so each increment can be released when the business is ready.
When it matters for buyers
- When a vendor proposes a Scrum engagement. The statement of work (SOW) may describe a team and a number of sprints rather than a fixed list of features. Check what is committed: team size and skills, sprint length, number of sprints, and how scope is decided.
- When you’re asked to supply a product owner. This is a real time commitment, often several hours a week or more. Projects stall when the buyer’s product owner is too busy to prioritize work or clarify what is wanted.
- When reviewing progress and invoices. Sprint reviews are your best checkpoint. If the team rarely shows working software, or “done” items keep reopening, raise it early. Pressure to finish sprints on time can also build up technical debt.
- In ERP and CRM implementations. Many integrators run configuration and build phases in sprints. Our CRM overview covers how implementation partners are compared.
Questions to ask vendors
- How long are your sprints, and which meetings will our people attend?
- Who plays the product owner and Scrum master roles, and what do you need from us?
- What is your definition of done, and does it include testing, security checks and documentation?
- How do you bill: per sprint, per person-day or fixed price per release?
- How do you report progress and forecast completion of the remaining backlog?
- What happens if a sprint’s goals aren’t met?
How it differs from Kanban
Kanban manages work as a continuous flow rather than in fixed cycles. Items move across a board, from to-do to done, and the team limits how many are in progress at once. Kanban has no required roles or sprint meetings, and priorities can change at any time rather than at sprint boundaries. Scrum gives more structure and a predictable review rhythm, which suits building a product in planned increments. Kanban tends to suit work that arrives unpredictably, such as support requests, maintenance and operations. Some teams blend the two, using a Kanban board within Scrum sprints.