What is Scrum?

When a software vendor says 'we work in Scrum', they are promising a precise mechanism — and knowing its parts lets you tell real practice from sales vocabulary. Work is divided into sprints, fixed cycles of one to four weeks that each end with something functional to show. Priorities live in a backlog ordered by a Product Owner, the role representing your business interest and deciding what gets built in what order — in commissioned projects this role is either yours or held by a vendor-side person executing your priorities, and clarifying which is the single most important contract detail. The team organises its own execution, with a Scrum Master guarding the process rather than assigning tasks, and rituals keep everything in the open: sprint planning, a short daily stand-up, the sprint review demo — your moment, where you watch software run rather than read progress reports — and the retrospective where the team repairs its own process. Two structural guarantees make this valuable to a buyer: rhythm, meaning a project cannot drift silently for months because every fortnight produces something inspectable; and explicit prioritisation, meaning direction changes are welcome but enter through the backlog at the next sprint, not through phone calls that whiplash the team. The counterfeit is easy to spot: 'we are agile' plus a single delivery in six months plus reports instead of demos is a waterfall wearing new vocabulary.