🗓️
A plain-English, picture-first introduction for people who have never worked in Scrum. About 15 minutes to read. No prior knowledge needed.
Think of renovating a house. You could agree one giant plan and see the result a year later. Or the builder could finish one room at a time and show you after each one, so the next room gets better. Agile is the second way.
| Official wording | What it means day to day |
|---|---|
| People and conversations over processes and tools | Talk to each other. Do not hide behind tickets and emails. |
| Working product over exhaustive documentation | Something that works beats a 50-page document about something that does not exist yet. |
| Working with customers over contract negotiation | Stay close to the people we build for and keep checking we are building the right thing. |
| Responding to change over following a plan | A plan is a best guess. When we learn more, we update it. |
The left side matters most to Agile, but the right side still has value. It is about emphasis, not "never write documents".
Key idea: a Sprint is a fixed-length box. It does not stretch to fit the work. Instead we adjust how much work we pick. That makes our delivery rhythm predictable.
One small team (typically up to about 10 people), with no sub-teams and no hierarchy inside it. Only three accountabilities:
Speaks for users and the business. Owns the Product Backlog and decides what is most valuable to build next.
Like: the person deciding what the team is trying to win this season.
Everyone who does the work: engineers, designers, testers, analysts. They decide how to do it and how much fits in a Sprint.
Like: the players on the pitch.
Coaches the team in Scrum, removes obstacles, protects the team's focus and helps meetings be useful. Not a project manager.
Like: the coach who clears the way so the players can play.
One ordered list of everything we might build, most important at the top. Never "finished"; it changes as we learn.
Promise: the Product Goal, where we are heading.
The items chosen for this Sprint, plus the plan to get them done. Owned by the Developers.
Promise: the Sprint Goal, one sentence on why this Sprint matters.
The working result at the end of the Sprint. Something real that could be used, not a pile of half-built parts.
Promise: the Definition of Done, a shared checklist for what "finished" means.
Everyone can see the real state of the work. No surprises.
We regularly stop and check: is this going the way we hoped?
If not, we change something quickly, while it is still cheap.
Every ceremony in Part 2 exists to support one of these three ideas.
Scrum's official word is "events", but most teams say "ceremonies". Each is time-boxed (it has a maximum length, so it never drags on) and each solves a specific problem. If you ever wonder "why are we having this meeting?", the answer is below.
Illustrative only. Exact days and times are a team decision (see "Our team agreements" at the bottom).
Tip: walk the board from right to left (closest to Done first). The question becomes "what will it take to finish this?" instead of "what did I do yesterday?".
| Remove this… | …and you get this | It answers |
|---|---|---|
| Sprint Planning | Unclear goals, random work, over-commitment | "What are we doing, and why?" |
| Daily Scrum | Blockers found too late, duplicated work | "Are we on track today?" |
| Refinement | Vague work, long painful Planning | "Is the next work clear enough to start?" |
| Sprint Review | Building the wrong thing, stakeholder surprise | "Did we build the right thing?" |
| Retrospective | Same problems repeat, no improvement | "How do we work better?" |
Kanban is Japanese for "signboard" or "visual card". Toyota used cards in its factories so workers only made more parts when the next step was ready. The big idea: make work visible, and do not start more than you can finish. In Scrum we use a Kanban-style board to show the Sprint Backlog: the work we promised for this Sprint.
Each card is one piece of work (a ticket in Jira). Each column is a stage. Cards move left to right until they are Done.
The numbers next to the column names are WIP limits, the secret ingredient (explained in WIP limits).
Want the why behind WIP limits? They come from Kanban and Lean rather than Scrum, so they now have their own page: WIP limits: stop starting, start finishing.
Says what changes for the user ("Add search filters"), not a vague activity ("Search stuff").
Ideally finished in a few days. If it sits In Progress for a week, split it.
A short list answering "how will we know it works?".
So everyone knows who to ask. Blocked cards get a visible flag.
| Scrum board (what we use) | Pure Kanban | |
|---|---|---|
| Time | Reset every Sprint | Continuous flow, no Sprints |
| On the board | Only what we committed to this Sprint | Everything in flight |
| Roles | Product Owner, Scrum Master, Developers | No required roles |
| Shared ideas | Make work visible · pull work · limit WIP · keep improving | |
Every card passes through two gates. Before it starts, we check it is clear enough to begin. That is the Definition of Ready. Before we call it finished, we check it really is. That is the Definition of Done. Think of a restaurant kitchen: the cook starts when the order is clear and the ingredients are on the counter, and a dish only leaves the kitchen once it is plated, tasted and safe to serve.
A short checklist that says when a card is clear enough for the team to pull into a Sprint. It is the “prepping the ingredients” check.
Asks: “Can we start this tomorrow without guessing or waiting?”
A short checklist that says when a card is truly finished. It is the quality check before a dish leaves the kitchen.
Asks: “If a user used this today, would it hold up?”
| Definition of Ready | Definition of Done | |
|---|---|---|
| The question | Is this card clear enough to start? | Is this card really finished? |
| When it is checked | Before the card enters a Sprint (in Refinement and Planning) | Before the card moves to Done |
| Who it protects | The Developers, from starting vague or blocked work | The Product Owner and users, from getting half-finished work |
| Part of official Scrum? | No. It is a popular team practice, so it is optional | Yes. The Scrum Guide requires one for every Increment |
| Kitchen version | The order is clear and the ingredients are on the counter | The dish is plated, tasted and safe to serve |
These are examples to start from. Your own lists should match your team’s work, because a design team’s “Done” looks different from a software team’s.
| Ceremony | What happens with Ready and Done |
|---|---|
| 🧹 Refinement | Cards are clarified until they meet the Definition of Ready. |
| 🗓️ Sprint Planning | The team pulls in cards that are Ready, and nothing vaguer. |
| ☀️ Daily Scrum | Look at the board: what is still missing before this card meets the Definition of Done? |
| 🎁 Sprint Review | Only work that meets the Definition of Done is shown as finished. |
| 🔁 Retrospective | Is either list too strict, too loose or ignored? Improve it. |
| Mistake | What goes wrong |
|---|---|
| No shared Definition of Done | “Done” means different things to different people, and surprises arrive at the Sprint Review. |
| Counting “almost done” cards | A card that is 90% done is not done. It is not shown at the Review and goes back to the Product Backlog to be planned again. |
| Using the Definition of Ready as a wall | Every request is answered with “not ready, come back later”, and work slows down. Keep it a checklist for a conversation. |
| Lists that are too long | Nobody remembers 25 items, so nobody checks them. |
| Changing the list quietly mid-Sprint | Cards that were Done suddenly are not. Change it in the Retrospective and tell everyone. |
| A list nobody can see | It lives in a document nobody opens. Put it on the board. |
Good to know: the Scrum Guide requires a Definition of Done. It has no Definition of Ready. It only says that items small enough to be finished in one Sprint are ready to be picked in Planning. Many teams add a Definition of Ready anyway because it keeps vague work out of the Sprint, so treat it as an optional tool.
Write your team’s own lists in Our team agreements below.
| Myth | Reality |
|---|---|
| "Agile means no planning or documentation." | We plan constantly in smaller pieces and write the documentation that is useful. |
| "The Scrum Master is the team's boss." | A coach and servant-leader. They do not assign work. |
| "The Daily Scrum is a report to management." | It is the team's own planning meeting. |
| "We can add work mid-Sprint if it is urgent." | The Sprint Goal is protected. Urgent items are discussed with the Product Owner and usually wait for the next Sprint, or something comes out. |
| "Velocity is a performance score." | It is only a forecasting tool. Comparing teams, or pushing it up, just inflates estimates. |
| "More meetings, less work." | Ceremonies are a modest share of a Sprint and replace many ad-hoc meetings. |
| Term | Meaning |
|---|---|
| Sprint | A fixed-length work cycle ending with a working result. |
| Product Backlog | The ordered list of everything we might build. |
| Sprint Backlog | The items chosen for the current Sprint plus the plan to do them. |
| Increment | The usable, finished result produced during a Sprint. |
| User story | A short description of a need from the user's viewpoint: "As a traveller, I want to filter results, so that I find what I need faster." |
| Story points | A relative size estimate (small, medium, large) instead of hours, used to see how much fits in a Sprint. |
| Velocity | How much work the team typically finishes per Sprint. For forecasting, not for judging people. |
| Definition of Ready (DoR) | The shared checklist for when a card is clear enough to be pulled into a Sprint. Optional, and not part of the Scrum Guide. |
| Definition of Done | The shared checklist for when work is truly finished. |
| Sprint Goal | A one-sentence reason for the Sprint. |
| Time-box | A maximum length for an activity. When time is up, we stop. |
| WIP | Work In Progress: started but not finished. |
| Blocker | Anything stopping a card from moving forward. |
| Stakeholder | Anyone affected by or interested in what we build. |
| Ceremony / Event | One of the regular Scrum meetings. |
Scrum is a framework, so every team fills in the details. Let us decide these together at kickoff or in our first Retrospective.
| Topic | Our decision |
|---|---|
| Sprint length | e.g. 2 weeks |
| Sprint start / end day | e.g. starts Monday, ends second Friday |
| Daily Scrum time and place | e.g. 10:00 at the board / video call |
| Sprint Planning | day and time |
| Refinement | day and time |
| Review and Retro | day and time |
| Board columns | e.g. To Do, In Progress, In Review, Done |
| WIP limits | e.g. In Progress = number of people, In Review = 2 |
| Definition of Ready | e.g. user need written, acceptance criteria agreed, small enough for one Sprint |
| Definition of Done | e.g. coded, peer reviewed, tested, deployed |
| Where the board lives | link to our Jira board |
Remember: Scrum is simple to describe and hard to master, and that is fine. Our first Sprints will feel clumsy. The Retrospective is there precisely so we get better every time.