Kanban vs. Scrum: What to Choose?

Both Scrum and Kanban provide an opportunity to make custom product development flexible and capable of supporting drastic changes in requirements without significant costs. Both of them involve the division of large projects into small atomic tasks with their consistent solution called user stories. The order of solving problems is determined directly by the team taking into account objective factors (priority, complexity, the importance of the following tasks). All user stories constitute a backlog, which is a set of all the tasks necessary for the project implementation.

In general, the team plays an important role in both methodologies (which does not contradict the Agile Manifesto). The main principle is free communication between specialists and general discussions. The team usually consist of up to 9 members without a formal leader and outside control of the workflow. That’s why it’s not possible to blame only one team member in the failure: in this case, the responsibility is borne by the whole team.

Usually, Scrum is referred to as a more directive model due to the numerous prescriptions non-characteristic for Kanban. First of all, it envisages small multifunctional teams, in which all the specialists necessary for solving the tasks are present. Each member of the team should have a clearly defined role. Every day a meeting (so-called daily meeting) is held where the team discusses what they did yesterday and what will be done today. Scrum Master is engaged in the organization of these meetings and the work process as a whole.

The prescriptive nature of Scrum is also expressed in the fact that all the work in creating IT products is divided into sprints equal in duration. This is done to maintain a certain rhythm of work, which can be considered an inalienable part of Scrum. Typically, the length of one sprint does not exceed 1 month, but recently companies increasingly work with 2-weeks sprints. Each sprint has several consequent stages as follows:

At the planning stage, the team refers to the backlog and selects the highest-priority tasks for execution in the newsprint. Basically, when making a decision, the priorities (defined by the Product Owner) play a role, as well as the impact of some tasks on the ability to proceed to other ones with the higher priority. Each task is evaluated by the implementation time. Thus, it is possible to take exactly as many tasks as the team can perform in the allotted time for one sprint. You can not change the list of tasks for a sprint until it is completed.

In Scrum, all efforts are directed to ensure that team members work simultaneously. Developers write code, and at this time tests are already being prepared by testers and documentation is being written by technical writers.

At this stage, the team should present the software products: workable, useful, and more functional than it was before the sprint.

Since Scrum strives to improve the process of creating products all the time, a retrospective is needed to discuss the problems that arose in the last sprint. The team meets together to find and discuss ways to solve these problems so that they do not recur in the future.

The main indicator that is measured in Scrum is the weight of the tasks performed during the sprint, that is, the team’s performance. This helps determine when the project will be completed if the team’s performance is at a certain level.

The first thing you will feel when reading about the same stages in Kanban is freedom. The methodology is based on team communication and joint decision-making, discussions, and following common sense.

At the same time, it lacks such a valuable advantage as the ability to pinpoint when the project will be completed, which is typical of Scrum. However, it is advisable to apply Scrum not on all the projects, that’s why we need an alternative.

In Kanban, planning begins when the Kanban board is run out of tasks. Sprints are not strictly defined, all work is divided into iterations, which are defined by the team.

IT products development goes on continuously, regardless of the other stages: planning, release, and retrospective. If you look at the Kanban board, each task has the statuses “Open”, “To Do”, and “Done”, although other statuses are also possible if the team decides they are needed in this particular project. At the same time, the team should specify how many tasks can simultaneously have the same status. If there is any jam, the rest of the team helps to eliminate it – in Kanban, there are no specified team roles.

The release dates are also determined by the team. This can be either a specific date or a day of the week. Because of this, Kanban has more flexibility and resilience to changes, as new tasks are added at any time. If you need to do something urgently, the team does not wait for the next sprint and each task remains in the work for as long as necessary until the team finishes it.

Since there are no sprints in Kanban, the retrospective is held on demand. The team meetings also may or may not be held.

An important Kanban indicator is the average time for passing the task on the board. In this case, the efficiency of the team is measured by the speed of completing the task from start to finish.

Your choice should be dictated by the features of the project itself, its requirements for the process flexibility. Despite this, the transition to flexible development methodologies is not always easy for teams. Therefore, it is recommended to start with Kanban: it is easier to implement due to fewer restrictions, you can add Scrum elements to it, if necessary. In addition, you can create cross-functional teams but still be divided into departments.

If you still can’t decide what is best for your project, do not puzzle. These methodologies can borrow certain features of each other while remaining equally effective for software building. If you like the certainty of Scrum, and at the same time the flexibility of Kanban, you can combine separate parts of the processes from both methodologies.

Remember: the task of methodologies is to optimize processes and not complicate them. Therefore, customize them the way it is convenient for you.