Agile project methodology for client web projects

Agile project methodology means running a project in short, fixed-length cycles. Each cycle ends with working output that the people who will use it review, and the plan for the next cycle changes based on what that review shows. It replaces one big plan signed at kickoff with many small plans, each tested against reality after a few weeks. For a web studio, that last part carries a condition most guides skip: agile only works when client input arrives at the same pace as your cycles.

That condition is the subject of this article. The values and frameworks are covered, but the focus is on what happens when the "customer" in the Agile Manifesto is a busy marketing manager who answers emails on Thursdays.

What agile commits you to before you pick a framework

Agile is a set of values, not a process. Lucid describes it as a philosophy guided by four values and 12 principles that prioritize flexibility and customer satisfaction. Scrum and Kanban are ways of putting those values into practice; neither is "agile" by itself.

The four values from the 2001 Agile Manifesto, each phrased as a preference:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The manifesto states that the items on the right still have value. It just ranks the items on the left higher. That nuance matters for agencies: "customer collaboration over contract negotiation" does not mean you skip the contract. It means the contract describes how you will decide things together, not every pixel up front.

Three terms carry the rest of this article:

• Iteration (or sprint): a fixed time box, usually one to four weeks, in which the team builds and reviews a slice of the product.
• Increment: the usable output at the end of an iteration — a live staging page, a working form, a finished template.
• Backlog: the ordered list of everything that might still be built, with the most valuable and best-understood items at the top.

The 12 principles, translated for client work

The 12 principles were written for software teams with an in-house customer. Here is what each one asks of a web project, and where it typically breaks when the customer is an external client.

Read the right-hand column as a risk register. If three or more of those breaks already describe a current client, fix them in the kickoff, not in sprint three.

Agile vs. waterfall on a website build

Waterfall runs phases in sequence — requirements, design, build, test, launch — and each phase is signed off before the next one starts. Coursera summarizes the agile alternative as an approach that emphasizes iteration, short-term development cycles, collaboration, and continuous improvement.

Neither approach is correct by default. The question is which kind of uncertainty your project has.

A practical decision rule: if you could write the full sitemap, page copy owner and feature list on day one and the client would sign it unchanged, waterfall is simpler and cheaper to run. If the client says "we'll know it when we see it", you need short cycles whether you call them agile or not.

Many studios end up hybrid: a fixed discovery and design phase, then agile sprints for build and content. That is a legitimate choice, as long as the contract says where the switch happens.

Scrum, Kanban and the other agile methodologies

Lists of agile methodologies usually run to seven or more entries, but for client web work only a few are in practical use.

Scrum

Mooncamp calls Scrum probably the most widely used agile methodology. It runs in sprints of one month or less, with three accountabilities and four events inside each sprint:

• Product owner: orders the backlog and decides what gets built next. On agency projects this is often split — the client owns priorities, the studio's lead owns the translation into backlog items.
• Scrum master: protects the process and removes blockers. In a small studio, this is usually the project lead wearing a second hat.
• Developers: everyone who builds the increment, designers included.
• Events: sprint planning, a short daily check-in, a sprint review with the client, and a retrospective for the team.

Scrum fits projects of six weeks or longer with a client who can attend a review at the end of every sprint.

Kanban

Kanban drops the time box. Work flows across a board (for example: Ready, In progress, Client review, Done), and each column has a WIP limit — a maximum number of items allowed in that column at once. When the "Client review" column is full, nothing new moves into it until the client clears an item.

Kanban fits retainers, maintenance work and solo designers handling many small requests. It also makes client delays visible on the board itself, which is often its most useful feature.

Scrumban, XP, Lean and FDD

• Scrumban keeps Scrum's planning and review rhythm but replaces fixed sprint commitments with Kanban flow and WIP limits. It suits studios where client requests interrupt planned work every week.
• Extreme Programming (XP) adds engineering practices: pair programming, test-driven development, continuous integration. Relevant when your studio writes custom code, less so for template-based builds.
• Lean focuses on removing waste — waiting, rework, handoffs. Its "waiting" category describes most agency delays precisely.
• Feature-driven development (FDD) plans by client-visible features ("contact form with CRM sync") rather than by technical task. The naming habit is worth borrowing even if you never adopt the full method.

The client is a sprint dependency — budget for it

Here is the mechanical problem with agile on client work. Every sprint ends with a review, and most backlog items need something from the client before they can start: copy, a logo file, a login, a decision. If those inputs arrive late, the sprint does not shrink politely. It stalls.

You can put a number on it. A two-week sprint has 10 working days. If one client review round takes three working days to come back and the team cannot proceed without it, 3 of 10 days — 30 % of the sprint — sit idle or go to filler work. Two blocking review rounds in one sprint push that to 60 %.

From that arithmetic comes a planning rule: keep blocking client turnaround at or below 20 % of the sprint length. On a two-week sprint, that is two working days per blocking round. If your client realistically needs four days, you have three options:

• Lengthen sprints to three weeks (15 days, so a three-day turnaround lands at 20 %).
• Move client reviews to the sprint boundary only, so no mid-sprint round blocks work.
• Switch to Kanban, where the wait shows up as a full "Client review" column instead of a failed sprint.

Track the real figure for two sprints before choosing. Studios that log it often find the client's average turnaround is longer than the number they quoted in the proposal.

A definition of ready for client inputs

Scrum teams use a "definition of done" to decide when an item is finished. For agency work, a definition of ready — the conditions an item must meet before it may enter a sprint — does more to protect the schedule. A workable version:

• All client-supplied files for this item are uploaded and open without errors (logo in vector format, images at usable resolution)
• Final or approved draft copy exists for every text block in the item
• Any third-party access the item needs (domain, hosting, CRM, analytics) has been granted and tested
• The decision-maker for this item is named, with a review deadline agreed
• Acceptance criteria are written in one or two plain sentences the client has read

An item that fails any line stays in the backlog. That rule feels strict in week one and saves the schedule in week four. If your intake process cannot produce these inputs reliably, look at how project briefing software for designers structures brief collection before the first sprint starts.

Agile project plan example: a six-week brochure site

This fictional example shows a 12-page company site run as three two-week sprints, with the client inputs each sprint needs listed explicitly.

Two details make this plan agile rather than a waterfall with sprint labels. First, the backlog for sprints 2 and 3 can change after the sprint 1 review — if the client sees the homepage and decides the services need a comparison page, it goes into the backlog and something else moves down. Second, each sprint ships something the client can click, not a status report.

Plan the November–December sprints before you start them

November and December are when a two-week sprint is most likely to collide with the year-end.

The risk is predictable: a sprint that ends in the last week of December may have no reviewer. A client whose office closes over the holidays cannot approve anything, and the sprint review slides into January along with every item waiting on it.

Three things to do in November:

• Ask every active client two dates: the last day they can review before the break, and the first day they are back. Put both into the sprint calendar, not just your notes.
• End the last pre-break sprint on or before the client's last review day. If that leaves a short final sprint, plan it as a hardening sprint — bug fixes, accessibility checks, documentation — that needs no client input.
• Collect January's inputs before the break. Copy, photos and access for the first sprint of the new year should already be in your hands when the client leaves, so the team can start on the first working day without waiting for an inbox to be cleared.

For projects starting in January, use December for sprint 0: brief, sitemap and backlog. That phase needs answers, not reviews, and clients often find time for a structured questionnaire more easily than for a meeting.

Agile metrics that tell you something on client projects

Agile metrics are measurements of how work flows through the team, used to plan and to spot problems early — not to rank individuals. Five are worth tracking on agency work:

• Velocity: the amount of work (in story points or simply item count) completed per sprint. Useful for forecasting after three or more sprints; meaningless when comparing two teams.
• Cycle time: days from "started" to "done" for one item. Rising cycle time on similar items usually means something is blocking them.
• Lead time: days from "requested" to "done". The number the client experiences.
• Burndown: remaining work plotted against days left in the sprint. A flat line in the middle of a sprint often means the team is waiting on something.
• Client wait share: days an item spent in "Client review" or "Waiting for input", divided by its total lead time. This is the metric most agile guides leave out, and on design projects it is often the largest single component of lead time.

Client wait share connects directly to the 20 % rule above. If it sits above 0.3 for most items, the problem is input logistics, not team speed. The blocked-time ledger in project management for freelance designers is a simple way to record it without a dedicated tool.

Where agile goes wrong in design studios

Most failed agile projects in agencies fail in one of four recognizable ways.

The mini-waterfall. The team runs sprints internally, but the client sees nothing until a "big reveal" in week eight. You get agile's meeting load with none of the early feedback. Early warning sign: no client attended a sprint review in the first month.

Agile words on a fixed-scope contract. The proposal promises flexibility, the contract fixes every feature and the price. When the client changes direction in sprint two, both sides reach for different documents. The fix is a written change rule: new items enter the backlog freely, but adding one to a fixed-budget project means naming the item it replaces. Defining that in the scope document up front is far easier than negotiating it mid-project.

Ceremony without a team. A solo designer running daily stand-ups with themselves, sprint planning for one person and retrospectives nobody reads. For teams of one or two, Kanban with a weekly review and a monthly retro usually captures the benefit with less overhead.

The backlog lives in email. Requests, files and approvals arrive across email, chat and calls, and the "backlog" is whatever the project lead remembers. Velocity and cycle time are impossible to measure because nobody knows when an item really started.

The 20-point fit test: should this project run agile?

Score each line 0, 1 or 2 before kickoff. This is a decision framework built for small studios, not an industry standard; adjust the thresholds after a few projects.

14–20 points: run Scrum with two- or three-week sprints. 8–13 points: run Kanban or Scrumban; keep a review rhythm but drop fixed sprint commitments. Under 8 points: run a plan-driven project with clear milestones. Agile labels will add meetings without adding feedback.

Lines 2, 3 and 7 carry most of the weight in practice. A project scoring 0 on all three will struggle under any agile framework, regardless of the total.

Which tool is used for agile methodology?

There is no single agile tool. Teams commonly run sprint and Kanban boards in tools such as Jira, Trello, Asana or Linear; a physical whiteboard works too for a co-located team. The board is the least important choice. What matters is whether the tool can show the states your work actually passes through — including "waiting for client" — and whether clients can participate without a paid seat. The project management tools comparison scores those criteria for studio use, including guest-to-seat ratios.

Boards track the team's work. They are usually weaker at collecting what the client has to supply: briefs, files and approvals. That is a separate job, and it is the one that decides whether items meet the definition of ready. cluein.me handles that side: each client gets one portal link to complete a structured brief, upload files and give approvals, without creating an account, and you export the organized assets as a ZIP with the brief in JSON and Markdown. The sprint board then starts from inputs that already exist, instead of from an email thread.

FAQ

What are agile metrics?

Agile metrics measure how work flows through a team so it can plan and catch problems early. Common ones are velocity, cycle time, lead time and burndown. On client projects, add the share of lead time an item spends waiting for client input, because that figure often explains delays the other metrics only show.

What are the 12 principles of agile methodology?

They are the guidelines behind the Agile Manifesto: early and continuous delivery, welcoming change, frequent delivery, daily collaboration with the business side, trust in motivated people, direct conversation, working output as the measure of progress, sustainable pace, technical excellence, simplicity, self-organizing teams and regular reflection. The table near the top of this article maps each one to web project practice.

What are agile and lean methodologies?

Agile is a set of values for building in short cycles with frequent feedback; Lean is a set of practices for removing waste such as waiting, rework and unnecessary handoffs. They overlap heavily, and Kanban draws on both. In agency work, Lean's focus on waiting time is a useful lens for client delays.

Which tool is used for agile methodology?

Any board that shows your workflow states can support agile, from Jira, Trello, Asana or Linear to a physical whiteboard. Choose based on whether it can show "waiting for client" as a real state and whether clients can take part without paid seats. Collecting client briefs and files is often better handled in a separate client portal.