Starting Scrum from scratch: a first month

The hardest part of starting Scrum is not learning the framework. It is deciding what to do on Monday morning when there is no backlog, no agreed roles and no habit. A short, deliberate start saves months. It does not need to be complete. It needs to reach a first Sprint that produces a real Increment and a first Review that teaches something.

What the Guide says you need

The Guide's description of the framework gives the checklist almost directly. A Scrum Team of one Scrum Master, one Product Owner and Developers, with no sub-teams, small enough to be nimble, cross-functional and self-managing. A Product Goal, in the Product Backlog. A Product Backlog, ordered, with the top items refined. A Definition of Done, created by the Scrum Team if the organisation has none. A Sprint of a month or less. And stakeholders for the Review. The Guide adds the reminder that Scrum is simple: try it as is and determine if its philosophy, theory and structure help to achieve goals and create value.

The GOV.UK guidance on agile planning offers a useful frame for the start: have a vision that people understand, define objectives you can check, keep a roadmap that looks ahead but is easy to change, and make detailed plans only for the work you are about to do.

Before week one: is it worth starting?

Spend an hour on the questions in when Scrum fits and when it does not. Is there a product with uncertainty in it? Can someone decide what to build? Can the team deliver something usable in a month? If the answers are no, solve those first.

Week one: foundations

Name the roles. A Product Owner who can decide and has time. A Scrum Master, even part-time, who will learn the framework and coach. Developers who between them hold the skills to build and verify the product. Check that the Product Owner has real authority. See the proxy Product Owner problem.

Write the Product Goal. One sentence about what the product should achieve. See writing a Product Goal. If you cannot write one, hold a short workshop with the sponsor.

Learn the basics together. Read the Guide, which takes an hour. See how to read the Scrum Guide. A common mistake is for only the Scrum Master to know it.

Agree where the work lives. A board, physical or digital, and a place for the Product Backlog.

Week two: the first backlog and the Definition of Done

Build a first Product Backlog. List what is wanted, ordered by value and risk. Aim for twenty to forty items, with the top ten described well and the rest as headings. Do not try to complete it.

Refine the top. Take the top five or six items and discuss them with the Developers: what is needed, how will we know it works, how big is it? Split anything too large.

Write a Definition of Done. Five lines the team can really meet. Review it after the first Sprint.

Choose a Sprint length. Two weeks suits most new teams. See choosing a Sprint length.

Identify stakeholders. Who will come to the Review? Invite them now.

Week three: the first Sprint begins

Hold Sprint Planning. Follow the Guide's three topics: why is this Sprint valuable, what can be done, how will the work get done. Keep the scope modest. Write the Sprint Goal. See planning your first Sprint.

Start the Daily Scrum. Same time and place each day, fifteen minutes. Use the board.

Keep the Sprint Backlog current. Update the board as work moves.

Refine in the background. A short session mid-Sprint on the next items.

Week four: the first Review and Retrospective

Hold the Sprint Review. Show the working Increment to stakeholders and get their reactions. Only work that meets the Definition of Done is shown. Adjust the backlog based on what you hear.

Hold the Retrospective. Look at how the team worked, not only what it built. Choose one improvement for the next Sprint.

Start Sprint two immediately, as the Guide says a new Sprint starts straight after the last.

A checklist

A worked example

This is an illustrative team of five at a small company, building an internal booking tool for training rooms.

Week one: the operations manager is named Product Owner, with two hours a day. A Developer volunteers as Scrum Master and reads the Guide with the others at lunch. The Product Goal: "Staff can book a room in under a minute, and double-bookings stop." Week two: the Product Owner and team list 30 items. They refine the top six: view availability, book a room, cancel a booking, recurring bookings, email confirmation, an admin view. Definition of Done: tested, reviewed, deployed to the test site, shown to the Product Owner. Two-week Sprints.

Week three: planning produces the Sprint Goal "a person can see free rooms and book one". They pull four items. Daily Scrums start at 9:30. Week four: the Review shows a working booking page to eight staff. One says it should show room size. The Product Owner adds it. The Retrospective's action: have stories refined two days before planning.

By the end of the month the team has a rhythm, an ordered backlog and its first feedback. It has also found out that its test site is slow, which goes on the list.

What to leave for later

• Story points and velocity. Count items first.
• Elaborate tools. A simple board will do.
• Scaling, metrics beyond a few, and detailed roadmaps.
• Every retrospective format. One simple one is enough.
• Perfect refinement.

Common mistakes

• Starting with the tool. Pick the practice first.
• A Product Owner with no time. Everything waits on them.
• No Definition of Done. Quality becomes an opinion.
• A first Sprint that is too ambitious.
• Skipping the Review because there is "nothing to show". Show whatever exists.
• Not telling stakeholders what to expect.

How to practise it

Use the checklist on your own project and mark what is missing. Fix the first gap before anything else. In the simulator the Initiate phase walks through the same foundations, from the vision to the first release plan, before any Sprint begins.