Please note that this blog is archived and outdated. For the most current information click here!
This article does not intend to pit Scrum vs Kanban. Both methods have their unique value. Thus, we'll articulate the key differences and summarise the trade-offs between the two. In the end, you may wish to apply one or both of them both to your Way of Working. At WorkingMouse, we favour the Scrum approach within our Way of Working during development and then use a Kanban approach for support and short term hiring.
The difference in planning between Scrum and Kanban is regular versus on-demand. In Scrum, traditional planning happens at the beginning of an iteration (or sprint) which will usually last between 10-15 business days.
At the end of the iteration, the software is re-deployed. Following that, the team plans the next iteration. Kanban is a continuous flow of issues without an actual planning point. Once an item has finished a stage, e.g. 'Design,' it is on-demand pulled into the next stage, e.g. 'Development' like a production line. Each production stage should have a limit on the amount of items worked on at any one time.
The critical trade-off between the two here is immediate flexibility vs. how much the team can demand. In Scrum, can your product wait until the next iteration cycle for an item to be added? At the same time with Kanban, putting an issue into the production line will affect the work that is already in progress. Therefore, are you sure you won't block the production line with too many planning changes? If so, what will you have to pull out of production?
The estimation process between the two methods is polarising, with Scrum estimating proactively and Kanban retrospectively. In Scrum development, estimates happen before each iteration. Items should be broken down, so they are small enough to finish within the iteration, and time is applied to each item. There are many different methods for achieving Scrum estimates from traditional to scientific.
In Kanban software development, it is optional to estimate when items are completed. There's no set time on issues as they are pulled into the next stage, and it's dependent on what's in production. These estimates can even be done on items in the backlog. The Kanban estimates on complete items are lead time and cycle time. These provide an average estimate of the amount of time it takes for a task to move from start to finish. If you want to understand the present state for Kanban, a cumulative flow diagram (CFD) is the best analytical tool to understand the time it takes and the current workflow in production.
The trade-offs here are relatively straightforward, you can either know how long something will take or know how long something took. Either method relies heavily on trust in the team's estimation and skill. The question is, how vital are estimates to you? If you're working within a set budget, a Scrum approach may appeal as you will know what you're getting for every iteration before it begins. In Kanban, if you have no set budget and a continual amount of resources, this approach may be favoured.
Change requests are a direct reflection on planning. In Scrum, it's simple "no changes for you "... well, at least until the next iteration. As the items are estimated, and the iteration length is fixed, nothing can be changed. This can be frustrating, especially if there's an immediate need/issue. In Kanban, the freedom is all yours, put in your changes as you need them. However, with great power... you know the rest.
The pros and cons of the ability to change immediately are clear. It's a big pro to put in an immediate change, especially if that change relates to a product issue that is affecting many users. However, there is merit to the patience of Scrum. A difference you view as essential today could have other priorities trump it when it comes to the next iteration planning session. The ability to have a cooling-off period on your production line may be of benefit. This comes down to how to make the best decision. You should consider your data sources around product usage, customer-centric design (user experience, competitive offerings, pricing, market share, and industry trends.
This is where the structures between the two approaches show the separation of philosophy. Scrum has clearly defined roles. The roles are; product owner (you), who advocates for the end-user and manages the prioritization of the product backlog. The Scrum Master (our squad leads/project managers) who manages all of the meetings (or ceremonies). And, of course, the development team who delivers the work.
In Kanban, there is no single master. The team work collectively to collaborate and deliver a task that is on the board. Teams can enlist the help of a coach if they desire, but the coach has no influence on the product, unlike the Scrum Master and Product Owner.
The trade-offs here are between having a structured and unstructured approach. If you have a team that is experienced in working together and comprehends the domain of what the product should achieve, then a Kanban approach may suit. However, if there are multiple commercial parties, Scrum may be a better fit. At WorkingMouse, we treat the customer as the product owner. We have the domain experience in development and assume the product owner is bringing the domain experience for the problem we're solving.
Due to the continuous flow of Kanban, it removes a significant amount of project time bloat. This means ceremonies are kept to a minimal. Weekly 30-minute meetings or daily 15-minute huddles are ideal. A project manager's nightmare and everyone else's delight!
The Scrum approach has several vital meetings throughout the iteration cycle. The first is a planning session where the entire team draws upon the top priorities of the backlog and agree upon the user acceptance criteria (approximately 1 hour long). The second meeting is an elaboration session where the team confirms how they will solve the issues, and the time/risk estimations (approximately 1 hour, excludes product owner). Once development has begun, the team completes a 10-15 minute daily huddle that calls out who's doing what and whether any team member is experiencing blockers (1 hour per week, excludes product owner). Lastly, upon delivery, the team does a review (approximately 1 hour) and a retrospective to look for improvement opportunities (1 hour, excludes product owner). That totals 5 hours across a single iteration if all runs well.
The trade-off here is clear, 5 hours of every team members time put towards project development or use that time for project management? This is why iterations have a minimum of 10 days or two weeks as the team would get too bogged down with running ceremonies.
The two methods run the same project board. Issues flow through in the following sequence: To Do, In Development, Testing & Done. The difference is that Scrum has two stages before: a Product Backlog (which encompasses everything) and the Iteration Backlog (all functionality that will be completed in this iteration). The reporting on Scrum is via a burndown chart that tracks issue completion against iteration time. This can be summarised as the project's velocity. The Kanban reports are the lead and cycle times that feed into the Cumulative Flow diagram.
Again, this comes down to product responsiveness very project planning, and the type of project you are undertaking. In my experience, I've
never seen a Scrum project with an empty product backlog. There will always be more to do, and there will always be technical debt. Does
removing the product backlog free you as the product owner from this and enable a forward-thinking mindset or, is it essential that this
detail is never lost?
As you will now see, there's a fairly big difference between the two models. It may be best to reflect on how you like to work as a product owner? Do you prefer to work in a planned manner or reactively? Traditionally, Scrum works better for large projects that require structure such as software outsourcing while Kanban is between for fast changes, support/maintenance, and bug fixing. At WorkingMouse, we use the Scrum method in our Way of Working for project development but allow a Kanban approach to support where our clients choose what is going into support production or doesn't. We hope this article helps you find your Way of Working for your project.
Made with ❤️ in Milton, Brisbane (Meanjin) Australia.
WorkingMouse acknowledges the Traditional Owners and their continuing connection to land, sea and community. We pay our respects to them, their Elders, both past and emerging.
2026 WorkingMouse Pty Ltd. All Rights Reserved.
.png)
