Agile Project Management with Scrum and Kanban: How Modern Software Teams Work

What is agile project management and how do Scrum and Kanban fit into it?

Agile project management is a way of running software work in short cycles, with frequent delivery and constant feedback instead of one big plan. The Agile Manifesto defines its values. Scrum turns those values into a light framework with clear roles, events and artifacts, while Kanban focuses on visualising and limiting work in progress.

Clients on my web design and e-commerce projects often ask why developers talk about "sprints" and "backlogs". I have worked in digital marketing since 2012, so I have sat in many of those meetings. In this guide I lean on official sources for the theory and on my own experience for the practice. I do not compare tools here; that deserves its own article.

Why does the classic waterfall model struggle with software?

Waterfall runs work in a fixed order: requirements, design, build, test and release. On paper it looks tidy. However, software requirements change in the middle of a project. A client sees the first screen and suddenly knows what they really want. Meanwhile, the market moves. A competitor ships a new feature.

As a result, a waterfall team works for months and shows the product only at the end. Fixing a misunderstood requirement at that point is expensive. The pattern I see most often is simple. The contract scope is delivered, yet the real user need is still unmet. In short, the problem is not planning itself. It is the assumption that uncertainty will not show up.

That said, waterfall is not always wrong. It still works for fixed, regulated scopes that will not change. Most web and mobile products, however, do not fall into that group.

The agile answer is straightforward. If you cannot remove uncertainty, cut it into small pieces. You deliver in short cycles and collect real feedback at the end of each one. So a wrong assumption surfaces within weeks, not months. The cost of fixing it also stays small.

Which four values does the Agile Manifesto stand for?

Seventeen software practitioners signed the Agile Manifesto in 2001 in Snowbird, Utah. The text contains four value statements. Each one prefers the item on the left over the item on the right. Still, it does not reject the right side completely.

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

Notice that the manifesto is not a method. Specifically, it gives you no meeting calendar and no job titles. Therefore, whenever a team tells me "we are agile", I ask a follow-up question: with which framework? The answer is usually Scrum, Kanban or a blend of both.

How do the twelve agile principles show up in daily work?

Behind the values sit twelve principles. Still, you do not need to memorise them. A few of them, however, shape daily work directly. For example, the first principle puts customer satisfaction through early and continuous delivery of valuable software at the top. Another one calls working software the primary measure of progress.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
• Business people and developers work together daily throughout the project.
• Face to face conversation is the most efficient way to share information.
• Simplicity, the art of maximising the amount of work not done, is essential.
• At regular intervals, the team reflects on how to become more effective and adjusts.

My favourite is the simplicity principle. On client projects the biggest waste of time is building features nobody uses. So a good agile team first asks: what happens if we do not build this at all?

What is Scrum according to the Scrum Guide?

The Scrum Guide is a short document by Ken Schwaber and Jeff Sutherland. It holds the only official definition of Scrum. The guide describes Scrum as a lightweight framework that helps people, teams and organisations generate value through adaptive solutions for complex problems. In other words, Scrum is deliberately incomplete. The team fills the gaps with its own practices.

Scrum rests on empiricism and lean thinking. Empiricism says knowledge comes from experience and decisions follow what you observe. Lean thinking asks you to reduce waste and focus on essentials. Together they make agile project management evidence driven rather than guess driven.

The 2020 edition is less prescriptive than earlier ones. For instance, it replaced "Development Team" with "Developers" and describes the team as self-managing. It also stresses that Scrum works for any complex work, not only software.

What are the three pillars and five values of Scrum?

The guide builds empiricism on three pillars: transparency, inspection and adaptation. Transparency means the people doing the work and the people affected by it can see the process. Inspection means checking artifacts and progress toward goals often. Adaptation means adjusting the process or product as soon as you spot a deviation.

In addition, the guide lists five values: commitment, focus, openness, respect and courage. They sound abstract. In practice they have very concrete effects. Courage, for example, means raising a hard problem in the middle of a sprint. Openness means saying "we will not make this" early.

In practice, here is what I see. Teams that hang the values on a wall but hide bad news in meetings only follow the Scrum calendar. Consequently, you judge a team's maturity less by its ceremonies and more by how early it talks about problems.

Which roles does a Scrum team have and what is each one accountable for?

The Scrum Guide defines three accountabilities. According to the guide, a Scrum team is typically ten or fewer people, because smaller teams communicate better. There are no sub-teams and no hierarchies inside it.

For me this split is the most critical point. In many companies the Product Owner becomes a go-between with no real authority. The guide, however, says clearly that the Product Owner is one person and that the organisation must respect their decisions.

Is a Product Owner the same as a project manager?

No, they are different roles. A traditional project manager controls scope, time and budget and assigns tasks. In Scrum nobody assigns tasks. Instead, the Developers plan the work among themselves. The Product Owner answers "what" and "why" and stays out of "how".

Therefore, turning a former project manager straight into a Product Owner can backfire. That person needs to know the business and the customer and must be able to make priority calls. Likewise, the Scrum Master is not a management seat. It is a form of servant leadership.

I face a similar issue on the client side. When the decision maker on a web project is unclear, a sprint demo gets five opinions from five people. So the first thing I settle on any project is simple: who has the final word?

What is a sprint and why is it one month or less?

The sprint is the heart of Scrum. According to the Scrum Guide, a sprint is a fixed length event of one month or less. A new sprint starts right after the previous one ends. All other events happen inside the sprint.

Why keep it short? Because longer sprints let the Sprint Goal go stale, increase complexity and raise risk. A short cycle guarantees real feedback at least once a month. Also, during the sprint you make no changes that endanger the Sprint Goal, and quality does not drop.

Two week sprints are very common in practice, although the guide does not demand any exact length. When I plan a calendar, I use the date calculator to check sprint end dates against holidays. That way a sprint review never lands on a public holiday by surprise.

Which questions does Sprint Planning answer?

Sprint Planning opens the sprint. The guide timeboxes it to a maximum of eight hours for a one month sprint, and it is usually shorter for shorter sprints. It covers three topics:

1. Why is this sprint valuable? The Product Owner explains the value and the team agrees on a Sprint Goal.
2. What can be done this sprint? The Developers pick items from the Product Backlog based on past performance and capacity.
3. How will the chosen work get done? The Developers usually break each item into pieces of one day or less.

Together these answers form the Sprint Backlog. My advice is to write the Sprint Goal as one sentence. For example: "A customer can move from the cart to payment without errors." Then you can test every mid-sprint request against that single sentence.

How do you keep the Daily Scrum useful in 15 minutes?

The Daily Scrum is a 15 minute event for the Developers, held at the same time and place every working day. Its purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog when needed. Above all, it is not a status report for managers.

The old "yesterday, today, blockers" format is no longer required in the 2020 guide. The team can choose any structure as long as it stays focused on the goal. Moreover, moving detailed technical discussion to after the meeting saves everybody time.

• Run the meeting in front of the board and talk about the work itself.
• Discuss the item furthest from the Sprint Goal first.
• When a blocker appears, name who will solve it rather than solving it live.
• If a manager's presence turns it into a report session, say so openly.

In short, any Daily Scrum longer than 15 minutes signals a planning problem. Instead of stretching the meeting, open a quick working session right after it with the two or three people involved. Everyone else then goes back to work.

What is the difference between the Sprint Review and the Sprint Retrospective?

Both events happen at the end of the sprint, but they inspect different things. The Sprint Review looks at the product. The Sprint Retrospective looks at how the team works. For a one month sprint, the guide caps the Review at four hours and the Retrospective at three.

The Sprint Review is a working session, not a slide show. The team shows what it built, stakeholders give feedback and together they update the Product Backlog. On web projects I open real screens, often the live staging site. So the client judges the product on screen, not on a slide.

The Retrospective, on the other hand, is internal. The team looks at individuals, interactions, processes, tools and its Definition of Done. Then it picks the most helpful improvements and, where possible, adds them to the next Sprint Backlog. Otherwise the same complaint returns every two weeks.

What do the three Scrum artifacts and their commitments protect?

The Scrum Guide defines three artifacts and ties each one to a commitment. These commitments strengthen transparency and focus. The table below sums up the link.

The most underrated concept here is the Definition of Done. According to the guide, an item that does not meet it cannot be part of the Increment or be presented. On web projects my own definition usually includes a mobile check, a speed check, accessibility basics and core SEO checks. For example, I do not call a page done until I have checked its tags with the meta tag generator.

How do you order and refine the Product Backlog?

The Product Backlog is an ordered list of everything needed to improve the product. The Product Owner is accountable for that order. Still, they do not have to write it alone. Input comes from the team and from stakeholders.

Backlog refinement means breaking items into smaller, clearer pieces and adding description, order and size. The guide does not define it as a separate event. It describes it as an ongoing activity. In practice, most teams still reserve a short weekly session for it.

When I order a backlog I ask three questions. How much value does this item create? How much risk does it remove? Does it unblock other work? For instance, on an e-commerce project the checkout step comes before the blog module, because that is where the measurable conversion goal sits. My article on digital marketing KPIs offers a useful set of measures for this kind of prioritisation.

What is Kanban and where does it differ from Scrum?

Kanban is a method that visualises the flow of work and limits work in progress (WIP). The Kanban Guide names three core practices: defining and visualising the workflow, actively managing items in the workflow and improving the workflow definition. Kanban has no fixed sprints, required roles or ceremonies.

Put simply, Scrum gives you rhythm and Kanban optimises flow. Therefore it is more accurate to see them as answers to different problems than as rivals.

Why does a WIP limit make a team faster?

Doing fewer things at once sounds slower at first. In reality the opposite happens. A developer who starts five tasks at the same time keeps losing time to context switching and finishes none of them. A WIP limit makes the rule "finish before you start" visible to everyone.

The Kanban Guide highlights four flow measures: work in progress, throughput, work item age and cycle time. These measures describe actual flow, not estimates. Consequently, you can answer "when will this be done?" from historical data.

In my own work I watch work item age most closely. If a card sits in the same column for days, something is stuck there. Moving that card to the top of the next Daily Scrum usually solves the problem before it grows.

When does Scrumban or a hybrid model make sense?

Many teams use neither pure Scrum nor pure Kanban. They keep the sprint rhythm and add WIP limits to the board. In the field, people often call this blend Scrumban. Both the Scrum and the Kanban communities also publish guidance on using the two together.

• The team builds new features and also handles urgent support requests.
• Work keeps getting added mid-sprint, so the Sprint Goal breaks often.
• The team ends each sprint with many half finished items.
• A product in maintenance mode no longer needs big planning meetings.

On the other hand, a hybrid should not be an excuse. Some teams that say "we run our own flavour of agile" have simply dropped the retrospective. So I recommend writing down which practice you dropped and why.

What are the most common agile project management mistakes?

The mistakes I have seen over the years look very similar. The biggest one is adopting agile project management on paper while still working like a waterfall team. Here are the ones I meet most often:

1. Presenting an "80 percent done" report instead of a working Increment.
2. Giving the Product Owner role to someone without decision rights.
3. Never adding retrospective actions to any sprint.
4. Using velocity to compare the performance of different teams.
5. Starting work without a written Definition of Done.
6. Turning the Daily Scrum into a reporting meeting for a manager.

The fourth mistake is especially harmful. Teams start inflating their estimates and the number loses its meaning. In short, a metric is a learning tool, not a punishment tool.

Are user stories and story points required in Scrum?

No, neither appears in the Scrum Guide. A user story is a short sentence that describes a need from the user's point of view: "As a customer, I want to track my order so that I know the delivery date." Story points are a unit for estimating relative size. Both are popular complementary practices, not rules.

This distinction matters. Some teams spend half of Sprint Planning debating points and believe Scrum requires it. The guide only asks that backlog items carry some notion of size. How you measure it is the team's call. T-shirt sizes, day estimates or simply counting items all work.

My advice is not to turn estimation into a negotiation. Its purpose is to help the team see what it can realistically finish in a sprint. Also, add acceptance criteria to every story. Then the "is it done or not" debate happens during planning, not during the review.

How do remote teams run Scrum events?

The Scrum Guide does not require events to be face to face, so distributed teams use the same framework. However, transparency does not appear by itself in remote work. You have to build it on purpose, with a shared digital board, a written Sprint Goal and decisions that live somewhere everyone can find them.

• Place the Daily Scrum at a fixed time where time zones overlap.
• Show the live product via screen sharing in the Sprint Review, not slides.
• Offer anonymous notes in the Retrospective so quieter members speak up.
• Write decisions into the backlog item instead of leaving them in chat.

My clients are often in different cities. Therefore I close each sprint review with a short video call and a written summary. Then stakeholders who missed the call still get the same information.

How do you adapt Scrum to agency and client projects?

Client projects differ from in-house product teams because budget and deadline often sit in a contract. You can still keep the spirit of Scrum. On my web design projects I fix priority rather than scope. So the most valuable pages and flows are finished in the first sprints.

At the end of every sprint I show the client a live staging site. Then they review a working page, not a design file. The design phase follows my Figma web design process, and development builds from approved screens.

When a scope change arrives, I do not argue. Instead, I ask the client which backlog item the new work should replace. As a result the budget stays fixed and only the order changes. That is customer collaboration over contract negotiation in real life.

How does Scrum scale when the team grows?

When a team grows too large, the Scrum Guide recommends splitting it into multiple cohesive Scrum teams focused on the same product. These teams share one Product Goal, one Product Backlog and one Product Owner. Scaling frameworks beyond that, such as Nexus, LeSS or SAFe, sit outside the guide.

On large corporate sites the team split also affects architecture. Each team needs a codebase it can ship independently. I covered this in my article on micro frontend architecture. Team structure and software architecture mirror each other, so you should plan them together.

My recommendation is to make sure one team truly works well before you pick a scaling framework. Otherwise you only move the chaos onto a bigger chart.

Which metrics show whether agile project management is working?

No single number is enough. On the Scrum side, meeting Sprint Goals and regularly producing usable Increments are the core signals. On the Kanban side, cycle time and throughput trends lead. However, all of these are process measures.

The real question is whether delivered software moves business results. For example, did the new checkout flow change the conversion rate? That is why I link the team board to business metrics. My article on conversion focused web design is a good starting point for that link.

• Process: Sprint Goal achievement, cycle time, work item age.
• Quality: bugs reaching production, rolled back releases.
• Value: conversion, user satisfaction, fewer support requests.

In short, if process metrics look great while value metrics look poor, the team is running fast in the wrong direction.

How should a team take its first step with Scrum?

You do not need a big training programme to start. First, read the Scrum Guide together as a team; it is a short document. Then move in small steps:

1. Name a Product Owner for the product and write down their decision rights.
2. Order the first Product Backlog and split the top items into small pieces.
3. Write the Definition of Done on a single page.
4. Start with a two week sprint and run every event in full.
5. After three sprints, decide in the retrospective what to change.

Do not get stuck on tool choice; you can run the first sprint on a wall board. For more articles like this, browse the software category. If you want help setting up a team and a process for your project, you can reach me through the contact page.