You know the name Scrum — but how do you actually do it?

Scrum is a promise: "this week, we'll at least finish this"

Instead of trying to finish a big job all at once, you cut it into short pieces, set a goal → get it done within that piece → look back, and repeat. Each piece is a sprint. Most teams make it one week.

With one-week cuts, delays show up within a week. A month-long plan stays quiet until week three, then everything piles into the last week, when there's no room left to adjust.

• Project — One contract. It has a period, and that period is split into weeks.
• Backlog — The list of big chunks to build in this project. About the size of "booking calendar" or "payment integration."
• Weekly sprint — Monday through Sunday. This week's goals, the task board and the retro all attach here.
• Task — A small piece of work you can finish in a day or two. It always belongs to some week.

The rhythm of a week — open on Monday, close on Friday

Four boxes are enough for a retro: what went well · what fell short · what we learned · what we wish for. Make it long and people stop doing it.

1. 01Monday · OpenCheck what didn't get finished last week, and pick the chunks from the backlog you'll take on this week. Write this week's goals in 2–4 sentences — not a task list, but "what should be done by the weekend" — then break them into tasks and assign owners.
2. 02Tue–Thu · RunIn the morning, write what you did yesterday, what you'll do today and what's blocking you; before you leave, write what you finished and what's left. Then move cards as far as the work has moved. That's it.
3. 03Friday · Close① Move all finished cards to Done ② check off this week's goals ③ write the retro ④ carry unfinished work over to next week. The order matters — you write the retro first because "why didn't we finish" has to be written while looking at this week's board.

Where people get stuck most — carrying over unfinished work

Copy it, don't move it. If you move cards to next week, last week's board goes empty and "what we meant to do that week" disappears. Keep the original and make a copy, and when you open the past week you can see results against the plan as they were.

And count how many times it's been carried over. If the same card carries over twice, three times, it's either too big or blocked. That's the signal to discuss in the retro whether to split it or drop it.

• Don't carry over early in the week. It would drag along cards you could still finish. If you want to postpone just one card, change only that card's week.
• Carry over after moving finished cards to Done. Cards you haven't moved count as unfinished and get carried over too.
• Past weeks' boards are a record. Don't touch the originals of cards that have already been carried over.

You can start once you decide just two roles

One person can do both. But that person ends up deciding both "what to build" and "how to protect the process" at once, so as the team grows it's better to split them.

• Scrum Master — The person who keeps the process from falling apart. Not someone who hands out solutions, but someone who asks questions so the team finds its own answers. The role is protecting the team.
• Product Owner — The person who decides what to build. They keep talking with leadership, teammates and customers to figure out what's needed, and they own the backlog. The role is growing the team.

You can start with docs, but you'll soon need a tool

You can follow the steps above with docs or spreadsheets. As long as you create weekly columns and stick to closing on Friday, you get most of the benefit. The problem is that someone has to create those columns every week — duplicating pages, fixing dates and moving unfinished items by hand, week after week.

Sprintingo has these steps built into its screens. Create a project and weeks are generated for its duration; move a card to Done and progress goes up; on Friday, one button copies unfinished cards to next week while last week's record stays intact. The product includes a sprint guide that answers questions like "when do I press Iterate?" with the real screens.

Frequently asked questions

How many days should a sprint be?

One week is the safest choice. Two weeks makes the plan loose, and three days doesn't leave enough to look back on. Start with one week and adjust once you see your team's pace.

How many items should go into a week?

There's no set number. Most teams overload the first two or three weeks; just look at how many you actually finished and cut back the next week. After two or three rounds, your team's real pace shows, and that becomes your baseline.

Can non-development teams use it?

Yes. Non-development work like planning, operations and support has its own board that shares the same weeks. For work without intermediate deliverables, though, it's better to write "what to check this week" instead of "what to finish."

Do we have to meet every day for the daily scrum?

You don't need to meet. If everyone writes what they did yesterday, what they'll do today and what's blocking them in the morning, and what they finished and what's left before leaving, you get the same effect. What matters isn't meeting — it's that blockers surface the same day.