Most explanations of SCRUM are written for Scrum Masters. They describe ceremonies, artefacts, and roles in terminology that makes sense if you are running the process but does not help you if you are the client paying for it.

This article is the opposite view. It walks through a typical 2-week sprint from the client's side: what happens, when you are expected to participate, what the team needs from you, and what you should expect in return. It is based on how we actually run engagements at codelabs.rocks, where client participation in sprint ceremonies is not optional; it is a precondition for the partnership working.

If you are about to start a custom software project and you have never lived through a SCRUM sprint as a client, this is the walkthrough you should read first.

The Shape of a 2-Week Sprint

A sprint is a fixed time window during which a defined set of work is delivered. Two weeks is the standard length. It is long enough to build something meaningful, short enough to correct course if the business need shifts. Every sprint produces working software that you can see, use, and evaluate.

Within each sprint, four ceremonies anchor the rhythm: sprint planning at the start, daily stand-ups, a sprint review at the end, and a retrospective after the review. You will participate directly in two of them (planning and review), pay indirect attention to one (stand-ups), and likely skip the fourth (retrospective, which is primarily for the development team).

Week 1, Monday: Sprint Planning

The sprint opens with a planning session, usually 90 minutes to 2 hours. The product owner (either you or a named representative on your side) sits with the development team and the Scrum Master to decide what will be built in the next 10 working days.

Before this meeting, the product backlog should already contain prioritised items. Sprint planning is not where you decide what is important; it is where the team commits to how much of what is already important can be delivered in two weeks. If you arrive at planning without a clear prioritised backlog, the session becomes chaotic. The work of prioritisation happens continuously, not in the planning meeting itself.

Your role: confirm priorities, answer questions about scope, clarify acceptance criteria. The team will ask specific questions like "when a dispatcher assigns a driver, should the system notify the driver automatically or should the dispatcher do it manually?" If you cannot answer these, the team has to guess, and their guess will sometimes be wrong.

Time commitment: 90 to 120 minutes, every other Monday morning.

Week 1, Tuesday through Friday: The Work Begins

With the sprint committed, the development team starts building. This is the phase where you see the least direct activity, but it is also when questions arise that need quick answers from your side.

Daily stand-ups

Every weekday at a fixed time (typically 9:30 or 10:00), the development team meets for 15 minutes. Each person says what they did yesterday, what they are doing today, and whether anything is blocking them. This is a team coordination meeting, not a client meeting. You do not need to attend, but you may find it useful to join occasionally just to get a feel for pace and any recurring blockers on your side.

Questions that need answers

During the build, the team will hit questions that were not resolved during planning. Some are trivial, some are material. The team will ask them via whatever communication channel you agreed on (Slack, email, Jira comments). Answering within one working day keeps the sprint moving. Delaying answers by three days effectively costs the team three days of progress, and those days do not come back.

We ask clients to commit to a decision turnaround time in writing. Most commit to 24 hours for normal questions and 4 hours for blockers. This is not bureaucracy; it is the single most important habit for keeping a project on track.

Time commitment: 30 to 60 minutes per day spread across messages, questions, and occasional quick calls.

Week 2, Monday: Mid-Sprint Check

Some teams include a lightweight mid-sprint check-in. This is a 30-minute session where the team shows what has been built so far and flags any scope risks. If a piece of work is going to be bigger than estimated, this is where you hear about it, and where you make the decision to either cut scope, extend the sprint, or push work to the next sprint.

Not all teams do mid-sprint checks formally; some handle this through asynchronous updates. Either way, you should have clear visibility into mid-sprint progress. If the first time you see the sprint's work is at the end, you have lost the chance to steer it.

Time commitment: 30 minutes if formal, or equivalent time reading updates asynchronously.

Week 2, Tuesday through Thursday: Final Build and QA

The middle of the second week is when features are being completed, tested, and integrated. QA engineers run through acceptance criteria. Developers fix issues found in testing. The team prepares a demo of what will be shown at the sprint review.

You should expect less communication from the team during this phase; they are in heads-down delivery mode. This is also when technical issues tend to emerge (a third-party API turned out to behave differently than expected, a performance concern needs to be addressed). These surface as questions to you about trade-offs: ship with a workaround, or push the feature to the next sprint?

Week 2, Friday: Sprint Review

The sprint closes with the sprint review. The team demonstrates working software: actual features running in a real environment, not slides or mock-ups. You try them, ask questions, and decide whether each piece of work is accepted or needs adjustment.

This is the most important hour of the sprint for you as a client. It is where you confirm that what was built matches what you needed, or catch the gap early enough that the next sprint can fix it. Skipping sprint reviews is the single fastest way to derail a project. Small misalignments compound across sprints, and by sprint five the gap between what is being built and what is actually needed becomes expensive to close.

Your role: review the demo critically. Approve what works, flag what does not, discuss what you did not expect. If something is not right, say so immediately, not in an email next week.

Time commitment: 60 to 90 minutes, every other Friday.

The Retrospective

After the review, the development team runs a retrospective: what went well, what did not, what to improve next sprint. This is an internal team ceremony. Clients are usually not invited, and that is intentional; the retrospective is most valuable when the team can speak candidly about what is working with the engagement, including what is working about the client relationship.

You can ask for the outcomes of the retrospective in summary form. Healthy teams are happy to share them. If the Scrum Master reports that the team raised a concern ("we are waiting too long for decisions," "the scope is drifting without explicit changes"), treat it as useful information, not criticism. The retrospective is where problems are named before they become crises.

What You Get at the End of Every Sprint

A well-run sprint produces a defined set of deliverables:

• Working software demonstrated in the review and deployed to a staging environment you can access
• Updated documentation for anything new (API endpoints, data models, user-facing changes)
• A burn-down or progress indicator showing what was completed vs committed
• A refreshed backlog with upcoming sprints re-prioritised based on what you learned
• Clear visibility into the hours spent, which in a T&M engagement is your invoice basis

Across 13 sprints (roughly 6 months), you will have seen working software 13 times, approved it 13 times, and adjusted direction up to 13 times. That is the fundamental value of the sprint cadence: there is no single "big reveal" at the end of the project, because you have been involved in the build every two weeks since the beginning.

Why This Rhythm Works Only When You Show Up

SCRUM is a collaboration model, not a delivery model. It works when the client participates in the ceremonies that require their participation, answers questions in the timeframes that keep the team unblocked, and treats the sprint review as the most important hour of every fortnight. It does not work when the client signs the contract, disappears for three months, and returns expecting a finished product.

At codelabs.rocks, we treat client participation as a precondition because 10 years of delivery have taught us that the projects that succeed are the ones where the client is in the room, reviewing working software, and course-correcting in real time. The ones that underperform are almost always the ones where the client tried to delegate the entire thing and discovered too late that custom software does not work that way.

What to Do With This

If you are about to start a custom software project, calendar the next six months of Monday planning sessions and Friday reviews now. Protect them. Send them to the deputies who will cover when you cannot attend. Commit to a decision turnaround time in writing. Read the sprint updates.

Two hours every two weeks, plus the daily attention that a serious project requires, is the minimum viable client participation. In exchange, you get working software every two weeks and the ability to steer it. That is the trade, and it is a good one.

‍