What a weekly sprint actually looks like at Kingdom
A day by day walk through of one sprint, from Monday planning to Friday demo, and why a one week rhythm keeps projects moving.
When we tell clients we work in weekly sprints, the next question is usually what that means in practice. Here is the shape of a typical week, using an example project: a Melbourne clinic that wants online booking and a site that explains its services properly.
Monday: agree on the week
The product manager reviews the board with the client. The board is a shared list of every task on the project, from “redesign the services page” to “connect the booking calendar”.
Together they pick what goes into this week. The rule is simple: only take on what can be finished and shown by Friday. If a task is too big, it gets split.
For our clinic, week three might look like this:
- Design the practitioner profile template
- Build the new services page from last week’s approved design
- Connect the booking widget to the clinic’s practice software
- Write copy for the physiotherapy and remedial massage pages
The whole conversation takes about twenty minutes.
Tuesday to Thursday: build, review, repeat
The designer, developer and tech lead work through the tasks. The client does not need to attend any meetings in the middle of the week, but they can see everything move across the board in real time.
When a task is ready for feedback it moves to the Review column and the client gets a link. Feedback goes straight onto the task. Small changes are usually done the same day.
The tech lead reviews every change before it goes live. This is the part clients never see and the part that stops a project from becoming fragile six months later.
Friday: demo and ship
On Friday the team shows what shipped. Not slides or a status report. The actual pages, working on a real URL.
The client approves, asks for tweaks, or adds new ideas to the board. Anything approved goes live. Anything new gets prioritised for Monday.
Why one week and not two
Many teams run two or four week cycles. We prefer one week for three reasons.
Feedback arrives while it is still cheap. If the direction is wrong, you find out after five days of work instead of twenty.
Nothing waits long for a decision. A question raised on Tuesday is answered by Friday at the latest, so work does not sit blocked.
Momentum is visible. Clients see progress every single week. That makes it easier to stay engaged, which makes the product better.
Fewer meetings, more visibility
The rhythm keeps meetings to a minimum. A short planning chat on Monday, a demo on Friday, and a board you can check whenever you want. Everything else happens on the tasks themselves.
If you would like to see what your first sprint would look like, book a strategy call and we will sketch it out with you.