We’re always in pursuit of the best tool or technique or methodology that we think will almost magically set us on the path to be super productive, super fast and super cool people who can fix bugs in minutes if not seconds; who can estimate stuff correct up to two decimal places and who can foresee any possible upcoming roadblocks. But, till that happens, we’ll have to make use of the current tools and techniques. Kanban or scrum —which one is better and how to choose between them, seems like the battle these days.
Scene from Matrix (Warner Bros / Village Roadshow Pictures / Groucho II Film Partnership)
So, how do you choose a methodology for your own use? If someone asked this a couple of years back, 99% of the respondents would have answered, “I think scrum fits well for my project work and so we use Scrum”. But things are changing now. There is another methodology that allows for easy-to-use yet very efficient project management activities - Kanban. While both Kanban and Scrum are related to the Agile family, they are different in many ways. It is important to understand their strengths and weaknesses to correctly decide which of these is the right option for you. In this post, I will compare Kanban vs Scrum on the basis of few core features and requirements in day to day activities. That will give you a clearer picture of what may suit your use case better.
Planning
Scrum stresses on planning. From sprint planning to sprint retrospective - there are several meetings meant to make sure the team is aligned about the next steps, priorities and learnings from previous sprints. This helps a lot as it is often important to know when to have something done, or what should be done on a given date, and also have your work organized following a goal, to have some stability in the team without changing everything every day.
Kanban on the other isn’t too keen on planning. It is open to taking changes on the go. That means there is less stability and things can change frequently. This is a good thing and a bad thing - depends on your project and the phase it is currently in. For instance if you expect unpredictable workloads over the time and don’t have a clear picture of the tasks upfront, Kanban can be helpful. But if you already have a well defined feature list with a clear timeline, it would be a mistake to use Kanban.
To put things in perspective, while developing Taiga we used Scrum before publishing our first release because we were focused on having an MVP on time, and because we could guarantee a complete dedication of the team, without unforeseen interruptions. After the release, we moved to kanban because we needed to guarantee the development of improvements to Taiga (software) living with the unpredictable work generated by the input received from real support queries, facilitating the prevention of bottlenecks at the different stages of the development process of new features (UX, design, development and testing), and allowing us to react faster to the market needs we had.
Estimation
We saw how Scrum stresses on planning beforehand, and so estimation has a very important role in Scrum. Developers may initially falter at estimations, let’s face it, all of us have failed at estimations, and sometimes very spectacularly. But, there are ways to handle this effectively. One way is to take up estimations is by considering the effort to perform a task over another, instead of thinking a task as a single activity. For example a “signup form” is twice harder than a “login form”, so you can assign one story point for the “login form” and two for the “signup form”. After a few sprints you can see how long these story points take to implement and the rate of burn points per sprint. The team can then logically estimate effort in upcoming sprints.
Kanban on the other hand has no mandatory requirements for estimation. Developers get stuff assigned to them and they work on it till it is finished or something very important comes up. So, if you have fair enough time and don’t mind getting few initial sprints wrong (in terms of estimations) and most importantly interested to understand your team velocity in order to get better task estimation later on - Scrum is the way to go. On the other hand, if you think getting tasks done is important at the cost of learning how fast the team is going, you can use Kanban and get on with it.
Charting
Both Scrum and Kanban recommend graphs to get an overview of team’s progress over time. These graphs not only give you a clear picture of how good or bad the team is doing, but also set a reference for future based on historical data.
Scrum recommends collection of time measurements made during sprints and uses it to calculate the average time taken by the team to finish a task, called the team velocity. There is also the burndown chart that graphically depicts the user story points against time passed. These charts and data are meant to help you get a clearer idea of team’s current status and whether or not the deliverables will be ready on time.
Similar to burndown charts in Scrum, you can also have Kanban burndown charts. There is another very essential graph called the CFD (Cumulative Flow Diagrams). It is useful for measuring the quantity of work in a given state, showing arrivals, time in queue, quantity in queue, and departure.
True agility
Scrum no longer asks for commitment from teams, rather it is about the sprint goals and forecasts. You can even negotiate the scope as per the Scrum Guide:
If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.
This helps make sure the teams don’t slog it out during the last few days of the sprint to just finish the tasks. If the tasks are difficult to finish during the sprint, there is always scope for negotiation with the product owners. This helps make sure that legitimate distractions (like bug fixing, clients support, urgent changes needed) during the sprint are accounted for and developers get proper time to accommodate all these activities.
Kanban on the other hand already relies less on time-boxing and forecasts. If something is urgent enough, developers can always change priorities and fix the important tasks first. This makes both of Kanban and Scrum pretty agile and easy to adapt based on the project situation.
Conclusion
In this post we saw how Kanban and Scrum take a little different approach towards planning and estimation. We also saw how both recommend charting and how they accommodate dynamic nature of software development in the modern world. There are several scenarios where Scrum may be a better choice than Kanban and vice-versa and it is finally your call to make a decision on what will suit your conditions better.
I suggest to refer this line whenever you are confused about Kanban vs Scrum - “Kanban suits teams that may need to quickly change their focus based on inputs from outside (customers, users, etc.) while Scrum is for teams that expect some sort of stability during the sprint”. Not to say that Scrum teams can’t change their focus during the sprint, but just that it is difficult for developers.
