July 4th, 2024

Kanban vs. Scrum: What's the Difference?

Kanban and Scrum are agile project management methodologies. Kanban provides flexibility with visual task boards, while Scrum offers structure with defined steps and timeframes. Kanban suits adaptability, while Scrum excels in organization.

Read original articleLink Icon
Kanban vs. Scrum: What's the Difference?

In the comparison between Kanban and Scrum, both are agile methodologies used in project management. Kanban offers flexibility through visual task boards, allowing tasks to be moved around easily. On the other hand, Scrum is more structured, with set steps and timeframes to follow. Kanban is ideal for adapting to changing needs, while Scrum excels in keeping projects organized. Kanban involves visualizing tasks on a board, optimizing task execution, and enhancing team communication and collaboration. Scrum, on the other hand, utilizes sprints, roles, artifacts, time boxing, and constant improvement to drive efficient project development. Both methodologies have their strengths and are suitable for different project requirements. Metrics like lead time and cycle time are crucial for measuring the effectiveness of Kanban, while productivity, predictability, and value are key for evaluating Scrum performance. Kanban is recommended for scenarios requiring clear visibility and control, while Scrum is beneficial for managing complex projects with multiple teams and a need for flexibility. Each methodology offers unique benefits to enhance project management practices.

Related

Formal methods: Just good engineering practice?

Formal methods: Just good engineering practice?

Formal methods in software engineering, highlighted by Marc Brooker from Amazon Web Services, optimize time and money by exploring designs effectively before implementation. They lead to faster development, reduced risk, and more optimal systems, proving valuable in well-understood requirements.

Bad habits that stop engineering teams from high-performance

Bad habits that stop engineering teams from high-performance

Engineering teams face hindering bad habits affecting performance. Importance of observability in software development stressed, including Elastic's OpenTelemetry role. CI/CD practices, cloud-native tech updates, data management solutions, mobile testing advancements, API tools, DevSecOps, and team culture discussed.

A Better Merge Workflow with Jujutsu

A Better Merge Workflow with Jujutsu

A new merge workflow using Jujutsu, a modern VCS compatible with Git, introduces The Austin™ Mega Merge Strategy®. It simplifies merge commits, amending commits, and selecting commits efficiently, enhancing collaboration and code review processes with advanced commit graph manipulation.

Show HN: A New Era in Project and Task Management

Show HN: A New Era in Project and Task Management

t0ggles is a project management tool with color-coded task cards for visual progress tracking. It offers AI task creation, GitHub integration, Public Boards, and a text editor. The platform's single paid plan costs $5 per user monthly.

Against Innovation Tokens

Against Innovation Tokens

The article explores the concept of "innovation tokens" in technology selection, cautioning about operational overhead issues. Emphasis is on prioritizing ease of operation over development benefits, advocating for consistent technology choices.

Link Icon 41 comments
By @largbae - 7 months
I much prefer Kanban to Scrum. It gets straight to the point which is "what is the next most important thing to do", and let's management/stakeholders worry about what's next while engineers focus on the current top of their heap.

Where Scrum wiggles its way into relevance is schedule. Most businesses need to be able to commit to some deadline with customers or coordinating teams, and scrum lets managers convince themselves that they can project 3-6 months of work into sprints.

The reality of course is that the requirements and deadlines are constantly moving and never match what was predicted, but you need _some_ prediction to coordinate large projects. So scrum just ends up being a hack to generate time pressure on the component tasks.

What's the right solution? So far in my life it comes down to Kanban and focus for engineers, plus an experienced leader that can guess reasonably well, pad for uncertainty, and renegotiate requirements to make that guess come true.

By @dasil003 - 7 months
Scrum is good for delivering small incremental results in a chaotic environments, and is popular because it naturally provides a tunable paper trail for mediocre managers to cover their asses with. But if you are trying to anything ambitious from either a product or engineering perspective then scrum will absolutely kill you, first by sucking the life out of your best engineers until they leave, and then obscuring any important ideas or real progress under a sea of administrivia.
By @asplake - 7 months
It slightly sets my teeth on edge to see the work items in Kanban referred to as “tasks”. The goal isn’t only to minimise wasteful multi-tasking locally, but to see deliverables flow through to the point of customer impact as smoothly as possible.

For me, the Zen of Kanban in product development is to work the board from right to left, working backwards from a "done" that means "someone's need was met" [1], stickies staying on the board until the learning is accounted for. You just don't get those senses of impact and learning if you think in tasks, and when tasks are managed at an unnecessarily fine granularity, I would consider it dysfunctional.

For what it's worth, I'm the author of Kanban from the Inside (celebrating its tenth anniversary in September) and Right to Left: The digital leader's guide to Lean and Agile (2019).

Edit: In case I am suspected of being anti Scrum, the reverse is true. Scrum done well can be truly great. Moreover, Scrum and Kanban are highly complementary to each other – they not only work in different ways, they do different things. As the article eventually acknowledges, there is no either/or here.

[1] agendashift.com/done

By @fendy3002 - 7 months
Scrum is developed as a solution to quick requirement changes and adaptability of development (agile), but I find that 2 weeks sprint planning and execution is actually the opposite.

If the requirement come during a sprint that'll change the scope, I don't find scrum can accommodate that. At best scenario cards are swapped with the new requirement. However at that point, scrum planning become useless, even to the point as being a hindrance.

So I treat my scrum board as Kanban board with two weeks checkpoint to measure velocity due to company rule. Honestly I prefer Kanban with periodical, flexible retro / planning.

By @nickd2001 - 7 months
In my experience as a dev... Kanban is a useful tool that helps teams organise work, break it down, be flexible. It helps the whole team to see what needs doing, identify dependencies and where to help each other out. Scrum OTOH looks similar on the surface, but is a form of micromanagement and becomes a system to be gamed. Project Managers become more concerned with velocity and burndown charts and whether specific stories were done in specific sprints or within the specific story points, than whether actual useful productive work is happening that moves the organisation forward. In the version of Kanban I've been in, you can chuck in the occcasional tech debt story into the so-called "sprint" (basically the 2 weeks between planning meetings) and no-one minds. Thus something that's slowing you down can be fixed. Whereas in Scrum, you'd have to haggle with the project manager to be "allowed" to do something like halve the build time in CI or something.
By @totallywrong - 7 months
The difference is that Kanban won't require a million useless meetings and will actually help you plan and get stuff done.
By @fancyfredbot - 7 months
I can barely read the title of this article without feeling an almost irresistible urge to say something nasty about scrum. Yet I'm not entirely sure why.

I don't think it's due to any specific requirement of scrum. Actually planning work in small increments, catching up with your team regularly, looking back and reviewing how things went, etc etc are mostly obviously good things.

I think it's the mistaken idea that a project manager can learn how to manage a team of software developers by learning scrum which I really dislike. I think that a good manager would do all of the core things scrum recommends more or less instinctively and wouldn't need an explicit process or framework to tell them how. Whereas someone who has learnt the scrum process but doesn't know how to code ends up creating a kind of ritualistic performance of management which is incredibly ineffective.

Often it feels like people believe they following scrum methods will let you run a team well without an expensive experienced manager, but this is not the case.

By @yobid20 - 7 months
23 yoe here working on lots of big projects across several industries. Scrum is the worst thing thats ever happened to the software industry. So much time wasted instead of getting work done. Micromanagement tool that benefits noone. Thankfully my current team switched to kanban about 1.5 years ago and we are no longer constrained and delivering feature after feature and new products. Scrum was a dark, dark period for all of us for about 10 years. Whoever came up with it should be shot, burnt, covered in acid, quartered, and tossed into a pit of hungry tiger sharks. It is literally the biggest roadblock to success we have ever seen. Once we switched away from it , it was an enlightenment to everyone and management was happy that we were delivering at a rate double to triple than we were when we had used scrum. No more effen story points and useless meetings anymore hallelujah.
By @_heimdall - 7 months
I've been on 5 or 6 different teams that used what they called scrum. I've never seem it work well, either it quickly devolves into an exercise in going through the motions or it's used as a micromanagement exercise on a team with little trust.

I have seen it occasionally help promote better communication within the team, like earlier calling out dependencies or having team members ask for help earlier. Communication is a different challenge though, scrum is too oppressive when the problem to solve really is just better, and more frequent, communication on a team.

By @smashedtoatoms - 7 months
This article is the what, but it is missing the why. I'm supremely biased against scrum, so basically ignore what I am saying if you're a fan of it. Fundamentally, Kanban is pull-based, and Scrum is push-based. That's the difference.

Scrum spends time determining how long things will take, and then attempts push it into a schedule via story pointing and other ceremony where people pretend they're not guessing how long thing will take by using points and t-shirt sizes and anything other than time to guess how much they can get done in some arbitrary amount of time. Then devs do what they were going to do anyway, and everyone slaps each other on the back because they're measuring the success they're having. It's a dream for people who like to count things and build check lists and check them off. Its success has little to do with the process and much to do with the team's ability to gather requirements and do their job. It's ideal for contract gigs where it's as important to track how much time it takes you to do things as it is to actually do things.

In Kanban you put what you want to do in a list, and pull the things from the list in order as you complete them. If customers need things quicker, you change the order of things in the list while communicating to them what will slip and what will accelerate. They take as long as they take (because that's how the world works, yes, even in scrum), but with 100% less ceremony and pointless coordination. Kanban is about constantly managing constraints and eliminating waste. You don't need to strictly measure how long things are taking. You pay attention when things don't move off the board, and modify resourcing in whatever way will get things unstuck. It's less fun because you don't get to pretend you know how long something will take, but it's more fun because you get to be an adult professional instead of a servant to the processes of people who don't actually build things.

This is somewhat tongue-in-cheek, but in my career I've never seen switching to pull-based patterns make things worse, and I've often seen them make things better, including morale. It doesn't seem like it will work, but in practice there are so many efficiencies gained in pull-based processes that it usually ends up being faster and feeling better while doing it.

By @inSenCite - 7 months
If you want to learn about scrum you are better off learning about XP which is a much superior engineering-centric methodology that Scrum takes heavy influence from.

Scrum can be useful as a way to get a team (and its leaders) going, build habits around releasing small batches/iterations of value but it is not particularly scale-able and puts a ceiling on the performance of a team. For leadership its a good way to get them to start loosening the reigns by having the right conversations.

The board part of Kanban is just one basic component. What gets skipped over are the EXPLICIT POLICIES that are refined over time i.e. what constitutes being in a column; the measurement of throughput (which is covered in the article); and a very high focus on continuous improvement (which includes the columns AND rows of the board, associated policies, and WIP limits)

Scrum gets a lot of hate because it's been commercialized and bastardized by people half-assedly doing it. It has a time and place. If you use a saw as a hammer you're not gonna have a good time.

By @darreninthenet - 7 months
Simple - Kanban when implemented properly in teams works brilliantly, Scrum when implemented properly in teams works "ok" and then tends towards Kanban as the team strives to modify it to work better. Solution - always start with Kanban
By @Xenoamorphous - 7 months
I never understood the obsession with this kind of thing. I guess it’s important to project managers and the like, but as a software developer? Just give me a list of prioritised tasks. You want me to be in a stand up saying what I did yesterday, what I’ll do today and what are the blockers? Fine, I’ll do that as long as the whole thing doesn’t take longer than 15 mins and you let me focus aftwewards.
By @wokwokwok - 7 months
It makes me laugh.

You know what’s true in this article?

That perception that scrum is really distinguished from kanban in that makes it easy to generate estimates.

…and easy to make, totally wrong estimates, are exactly what people pretending to do agile can use to do their (doomed) waterfall design and release plans.

That’s not agile. It’s stupid.

If anyone ever tells you that you need to swap from kanban to scrum so that you can get good estimates, you’re basically doomed to a future of dark scrum.

Run!

By @whimsicalism - 7 months
kanban boards - useful, easy to understand, help coordinate work

scrum - awful, mismanagement, micromanagement, useless meetings, overpaid consultants

By @skydhash - 7 months
From what I’ve seen, Kanban has:

  - No ritual meetings
  - No sprint (aka fake deadlines)
  - No story points (aka useless productivity proxy)
By @Smeevy - 7 months
One of the worst experiences of my career was having a terrible SAFe scrum master and their management team try to implement Kanban for my development team.

It somehow wound up being even more tedious and micromanaged than SAFe. I know that's the function the management, but it worries me when I hear someone think some new buzzwords will suddenly enforce careful planning and mutual respect.

By @katzenversteher - 7 months
I researched this like a decade ago and my conclusion at the time was that Kanban and Scrum kind of work the opposite way. Kanban is a "pull" approach where you have some kind of big goal you need (e.g. a car at toyota) and then all the dependencies (car parts and orders etc.) are pulled along with it into the pipeline (or todo list).

Scrum is "push" where small items are pushed into the pipeline (backlog) hoping the outcome is what is needed.

For an individual "worker" it's not that much of a difference, they have to work on the tasks anyways. The project might have different outcome / duration though.

By @osigurdson - 7 months
I find that people sometimes enjoy getting lost in the minutia of processes. After all, it is a lot easier than actually solving problems and shifts responsibility to artificial things which employees tend to love.
By @RecycledEle - 7 months
I just asked ChatGPT "Can you please tell me the difference in Kanban and Scrum in 2 paragraphs?" It gave me a better answer:

Kanban and Scrum are both popular Agile frameworks used to manage and improve work processes, but they have distinct differences in their approaches and practices. Kanban, originating from the Toyota Production System, focuses on visualizing work, limiting work in progress (WIP), and improving flow. It uses a continuous flow model, meaning tasks are continuously added and moved through stages such as "To Do," "In Progress," and "Done." Kanban emphasizes flexibility, allowing teams to pull work as capacity permits rather than adhering to fixed iterations. Its core principles include visualizing the workflow, managing flow, making process policies explicit, implementing feedback loops, and evolving collaboratively.

On the other hand, Scrum is a structured framework that uses fixed-length iterations called sprints, typically lasting two to four weeks. It defines specific roles such as the Scrum Master, Product Owner, and Development Team, and ceremonies like Sprint Planning, Daily Stand-ups, Sprint Reviews, and Retrospectives. Scrum emphasizes delivering a potentially shippable product increment at the end of each sprint. It promotes regular inspection and adaptation through its iterative cycles, aiming for continuous improvement and fast delivery of valuable product features. While Scrum prescribes a clear set of roles, events, and artifacts, Kanban is more flexible, allowing for the integration of its practices with other existing processes without requiring significant changes to the workflow structure.

By @vegetablepotpie - 7 months
This article is a pile of crap and no one should take it seriously.

> These methods often rely on cross-functional teams, where individuals with diverse skills work together to achieve project goals.

That is absolutely wrong. Scrum treats all developers as homogeneous. Any developer should be able to take on any story, and story points don’t change based on who is doing the story. There is nothing “cross-functional” about scrum, it is literally the opposite of that.

This article is jam packed with so many cliches that are popular with business writing that you would be forgiven in thinking that an LLM wrote it, things like “popular choice”, “making roles and responsibilities clear”, “high-quality work”, “ super adaptable”, “get excellent results”, “intuitive workflow”, “fast-paced nature”, “ finish high-quality projects”

> Our tool's "Sprint" feature allows work to be displayed on sprint boards

Ah, there it is, they’re selling something. But what are they selling?

> 'Earned Value Management' could be employed. It's a systematic project management process used to find variances in projects based on the comparison of work performed and work planned.

Look at the word “systematic”, they’re advertising that scrum teams can be compared to each other, despite the fact that the scrum guide says scrum teams cannot be compared to one another.

Leiga is selling project management software, but what they’re really selling is complacency to project managers. What this software will allow your boss to do is, instead of talk to you about your project, they can look at how many points you closed out in the last two weeks and then decide to throw you a pizza party or fire you. They’re selling socially acceptable complacency. They say to project managers, instead of doing your job, you can stay ignorant with our metrics, scale, and not work hard at all. That is a very compelling value proposition.

By @elzbardico - 7 months
Scrum is a set of prescriptions. Kanban is more of a phylosophy of production management.

Scrum is Jack Welch.

Kanban is Demming.

By @haunter - 7 months
I just leave the “I want to run an agile project” video here https://youtu.be/4u5N00ApR_k
By @jrs235 - 7 months
I see lots of comments about how awful Scrum is. In the comments it appears they are from people working on projects directly for their employer. Scrum's greatest value is for teams that are not directly employed. For example a contractor or consultancy. It's value is to align both parties to work towards providing the most value without having to deal with the up front cost and negotiation of fixed bid projects (and the buffer that is almost universally baked in to the price). Yes, it can be abused by the consultancy to continue to bleed the customer but if used in good faith usable software or value (able learnings/knowledge) is delivered at the end of the sprint. Then the customer can make a better informed decision on whether to continue on and/or what to work on for the next sprint (because they believe it will deliver the most value now).

Using Scrum and sprints to break a larger and fully committed project into small chunks can and will slow progress down due to the increased overhead and time consumed by sprint rituals. Use kanban for that instead.

By @xlii - 7 months
Many different definitions might just as well add mine.

Kanban is a method and Scrum is a process.

In a way that Kanban isn’t per se defined in time. It’s about how work is pulled (work in progress limits, just in time work prioritization) and presented (famous work board).

Scrum on the other hand is a time bound process. It creates cycles, sprints and ceremony. Kanban can be part of this process or not.

To provide simpler analogy - Kanban is a cake baking recipe and scrum is cake distribution process.

By @gepardi - 7 months
Kanban: See tasks that need to be done, do them and drag them to done.

“Scrum”, has turned into a ridiculous mess of meetings and estimation when we’re always bad at estimating. Then there’s the attachment to the “two-week” sprint and velocity blah blah blah.

It’s usually always frustrating.

I prefer Kanban.

By @FrankSansC - 7 months
By @mandeepj - 7 months
If you are exploring Kannan vs scrum, you’ve already failed before you even started.

First, what you are trying to do? Is it a big ambitious multi year project or even mid size which has a lot of modules? Then first you need to assemble a core team - PM, PO, Architect, Sr Engineer - and get the core components built to some extent or laid out clearly, before trying to find a suitable development strategy. In scrum, you should be ‘only’ integrating components and not developing, just like the assembly line.

By @olivierduval - 7 months
I always thought that Kanban is a tool and SCRUM is a method.
By @wodenokoto - 7 months
One of the things I don't understand about the HN crowd is how adamant the typical HN'er is about having good commit messages, and follow a strict merging paradigm, such as peer reviewed pull requests, with lot's of room for discussing minute details of rebasing versus merging with or without squashing.

But when it comes to a shared to-do list across a team, then that is apparently the worst thing to ever happen to a project.

I think it is pretty nice to have a place where we can all see what needs to be done, and how far along we are, and I think it is a pretty good idea to regularly review what in the to-do list we want to focus one. I don't think the core of scrum or kanban is bad, but I do think it drowns in managers who want to visualize and predict progress above actually pushing for progress.

By @nprateem - 7 months
The difference is when you use kanban someone suggests switching to scrum, and vice versa.
By @jmartin2683 - 7 months
Both are a hot mess in practice. I could imagine a scenario where this ‘flexibility’ in not knowing what you’re building ahead of time may be valuable but I’ve never lived one. I’d rather think it through?
By @cholantesh - 7 months
Quite like the difference between metal and visual kei, "Kanban is good, that's it!"
By @neilv - 7 months
I like modified Kanban boards, both when startup is in reactive mode, and as an alternate view of a really good Gantt model when I'm doing serious planning for less-reactive hitting of deadlines and synchronization points.

But if I were an agency doing hourly billing of clients who didn't know what they wanted, I would like Scrum. "C'mon, give us a straight answer to our questions, we're locking you into that for another 300 billable hours. Then you can pull other answers out of your behind in a week. We'll call it participatory design, or interactive, or something, and pretend it's that it's because this is the most efficient way to solve hard problems, or to be flexible at the superfast speed of business. But really it's because you are bad at what you do, and just pretending, so we decided you'll pay my firm 300 uninterrupted billable hours per week as your penance. I'm thinking of scaling up my team, so that we can bill-- uh, execute, faster."

By @osigurdson - 7 months
>> which has really changed how people work

Citation needed

By @kanbankaren - 7 months
Can I talk to your manager, please?
By @pestatije - 7 months
scrum: old buzzword...kanban? whatever, new buzzword in the making
By @bitwize - 7 months
I've become convinced that the first widespread software methodology is still the best one: PRIDE (Profitable Information by Design).

You probably haven't heard of PRIDE. It's on the verge of being lost to time. But the principles behind it have driven successful software projects for about 70 years now. It was originally released in 1971 by Milt Bryce through his company, Milt Bryce & Associates, based on Milt's experience leading major software projects dating back to UNIVAC in the 50s. Milt's son, Tim Bryce, continued to market the PRIDE methodology and materials until recently.

The thing about PRIDE is how comprehensive it is. It encompasses business analysis, business process design, database design, and software design and development; and every artifact from single requirements to code changes is given a tracking number (decades before JIRA or Git, and these numbers were at first tracked on paper!). It's not really focused on developing software but the design and construction of business systems. Computers are only a part of the overall puzzle, and programmers have a tendency to fixate on just that part and not see the big picture. What PRIDE provides is a framework for understanding the business as a whole, the information needs of the various business systems, and how to design procedures to be executed (by human or computer) to fulfill those needs. It starts with a comprehensive systems analysis phase (undertaken by systems analysts -- not programmers -- which profession has also been nearly lost to time) followed by an in-depth design phase. A common vocabulary is developed so that the business people and programmers can communicate in plain English. The database is also designed based on this vocabulary; in fact Milt Bryce was also the inventor of the concept of a "data dictionary". Then the software is designed, its design thoroughly documented, and then it's implemented by the programmers.

Compared to Scrum and Kanban, it's very waterfall-like and involves a lot of big design up front. That's a feature, not a bug. The solution to not knowing what your requirements are is to figure that bit out first and make sure the programmers have very clear goals before they write a single line of code -- not to put programmers in the driver's seat and have them make guesses at an implementation until the stakeholders say "yeah! That's it!" That means bringing systems analysts in and having them identify the systems, what data they consume, and what data to produce.

I think that PRIDE-like methodologies are going to be the future of software development, especially in this post-ZIRP era where the money is attracted to profitability, not the latest Silicon Valley fad. I've never been on a Scrum team that delivered on time or under budget. What's needed is more thought up front, and more discipline and accountability built into the process.

The current PRIDE book, PRIDE Methodologies for IRM: https://www.amazon.com/PRIDE-Methodologies-IRM-Tim-Bryce/dp/...

Tim Bryce's PRIDE web site: http://www.phmainstreet.com/mba/mbapride.htm

Old vid of Milt Bryce explaining PRIDE and ASDM (a suite of project management tools based on PRIDE written in COBOL): https://www.youtube.com/watch?v=SoidPevZ7zs