Understanding the Differences Between Scrum and Kanban

Scrum and Kanban are two workflow management systems that help implement agile and DevOps software development. Agile is a method developers use to break up large projects—which otherwise could take months to develop—into small chunks and test them along the way, and deploying an application in parts. This method of working helps DevOps discover and fix problems that happen along the way rather than waiting until a large project has been completed before evaluating how well it works. To work well in agile, DevOps typically adopts a workflow tool to keep the projects moving forward in a systemized manner to prioritize, manage, and execute work. The most popular of these tools are Scrum and Kanban.  

Scrum

Scrum is derived from the rugby term of the same name in which players come together to solve a problem, such as gaining the ball or completing a quick project, in the shortest amount of time. DevOps teams that use the Scrum framework work in sprints to complete a large project by breaking it up into smaller projects, and at the end of the sprint, they package the items and release them for deployment.  

At the beginning of each sprint, the product owner selects tickets from the product backlog, a prioritized to-do list, and then people from different teams like the Scrum Master, product managers, developers, quality assurance (QA) testers, and user experience (UX) designers decide on a sequence in which to complete specific tasks. Each mini-project is written on a card. The Scrum Master leads the discussion for the team to decide approximately how long it should take to complete the tasks on the cards and will only pull enough cards for a sprint, which typically lasts two weeks. So, one sprint may consist of five cards, but the following sprint may consist of eight. Each week, the team aims to complete all tasks on all the cards.

To keep the team organized and the work flowing in a preordained manner, the team uses a Scrum board similar to the one shown below in Figure 1. The board is generally organized into categories for each of the following tasks: To Do, Develop, Test, and Release.

A sprint consisting of eight tickets, or cards, might look like the board above.

The tickets, or cards, are placed on the board by the Product Owner who pulls tickets from the Product Backlog, which have been prioritized by stakeholders. Each sprint starts off with a clean board, unless in the unusual case in where there was a card left over from the previous sprint.  

The Product Owner has guesstimated the time it will take to complete all the cards and only puts as many cards on the board in the Sprint Backlog column as can be expected to be completed by the end of the sprint.

No work is pushed upon anyone. For the example in Figure 1, there is a developer team and a testing team. The testing team can only pull tickets from the column to their immediate left, which in this example is from the Dev Done column. But the team can pull as many or as few as it would like from the Dev Done column. If the team has only two people, each of them would only pull a ticket upon completion of another ticket. For this sprint, there are eight tickets, but had the project team felt like it could handle more for this sprint, there could be 10 tickets. Sometimes, there may be a ticket left over from the last sprint that never was completed. But in Figure 1, there were only eight tickets for the current sprint. The Product Owner at the beginning of this sprint pulled the most prioritized cards from the Product Backlog and put them up in the To Do column. The developers thus far, have already completed tickets one through four. The testing team has completed the tasks for Ticket 1 and is in the midst of working on Ticket 2. The developer team is currently working on tickets five and six. When someone on the Dev team completes a card, she moves it to the Dev Done column. The testers pull from the Dev Done column to do their work. If there are no Dev Done tickets and the testers are not testing anything, they can help the developers with the tickets they are currently working on in the Dev column. But as soon as a ticket moves to the Dev Done column, the testers go back to their regular duties of testing. This is the beauty of working in a DevOps culture as there is a shared responsibility for the software developers and operations build: the two teams help each other. At the end of the sprint the Product Owner packages the tickets in the Test Done column up for release.

That scenario is above is how the Scrum board works. Below are some more details about Scrum.

Daily Scrum

Every morning at the same time, everyone attends a meeting, commonly referred to as the stand-up, where each contributor to the project reports on their progress and issues that have arisen since the last stand-up. These daily meetings, which lasts about 15 minutes, hold everyone accountable for their work and allow people to discuss improvement ideas.

The Process

After the stand-up, people get to work, and over time, the cards gradually make their way across the board. For a sprint that lasts two weeks, by the middle of the second week, it’s expected that the cards have moved at least one step. It’s always a race to get everything done by the end of the sprint so the services they built can all be released. Anything that was not completed during a sprint stays on the board for the next sprint.

Retrospective

A retrospective meeting is held after each sprint to discuss what went well and what can be improved upon in following sprints. The team often discusses the best ways to improve the processes, tools and communication between teams and team members, as well as the action items the team will commit to for the next sprint.

Team Leaders

Overseeing the team are the Scrum Master and the Product Owner. Although the Scrum Master has no management authority over the team, she is responsible for ensuring everyone on the team understands Scrum theory and practices and for promoting improved engineering practices. A Scrum Master who holds a certification as a Scrum Master helps the team perform better and ensures the output meets the product objectives.

The Product Owner constantly re-prioritizes the Product Backlog, ensures the product meets the needs of end users, and decides when the team needs to continue developing the product and when to release it.  A product owner who holds the Certified Scrum Product Owner title helps ensure that the team works well together and the product meets business needs requirements.

In summary, the Scrum events consists of the following steps:

Scrum Recap

Scrum starts with a product owner, called the Scrum Master, who’s responsible for the project’s outcome and keeps stakeholders and DevOps informed on the project’s development. The product owner also looks at results of A/B tests to determine how users are interacting with the product and how it best functions. With Scrum, you break down your large project into phases and those phases into smaller pieces that can be completed by a cross-functional team within a prescribed time period, called a sprint, typically between two and four weeks. Once the sprint begins, you are not allowed to add in any new requirements. The Scrum process starts with a product owner creating a product backlog, a list of all that needs to be done and then prioritizing it, such as Requirement 1, Requirement 2, and 3. The requirements are set by the product owner after discussing it with the development team.

Then the product owner and development team attend the sprint planning meeting run by the Scrum Master. During sprint planning, the team pulls a small chunk from the top of product backlog items to work on during the sprint. That chunk becomes the sprint backlog, the set of tasks that the scrum teams decide to deliver for that particular sprint. As the sprint progresses, the development team performs the work necessary to deliver the backlog items by the end of the sprint. On a daily basis, the development team uses the daily scrum meeting to assess its progress. The scrum team uses a tool called a scrum board. It’s a visual representation of the workflow, which generally has four or more columns—Backlog, To Develop Test, and Done. Different tasks are placed in each column, indicating the progress of individual development items, or user stories. The cards move from the Backlog to Develop to Test and then, finally, to Done. At the end of each sprint, the development team delivers a functioning piece of the product to show for their work. The development team holds a sprint review to demonstrate to stakeholders what was accomplished during the sprint. After the sprint review, the team gathers for a sprint retrospective to discuss what went right or wrong and where they can make improvements for further sprints. Scrum teams follow an inspect-and-adapt approach. This means they improve continuously, taking lessons from their previous sprints.

Both Scrum and Kanban limit the work in progress, identify bottlenecks and improve productivity. They both break down large tasks so they can be completed efficiently and place a high value on continual improvement.

Kanban

Kanban, a Japanese word that means signboard or billboard, is a workflow management system that helps teams visualize their work, become more efficient and continually improve. Originating in the manufacturing industry, Kanban was later adopted by Agile software development teams and has since been adopted by other business lines throughout a variety of industries.

Like Scrum, Kanban, uses a board to visualize and manage work. The columns could be the same as the one in Fig. 2 below or could include many other columns to suit the project and team. The work items that need to be done are put on individual cards and present important information about a task, such as the names or job roles of the people who will handle the work item, a brief description of the job being done, screenshots and technical details that help explain the task, and the amount of time the piece of work is estimated to take.

Kanban Cards

The cards for projects start off on the far-left column of the Kanban board and travel from left to right across the board, allowing team members to see the status of any work item at any point in time.  If a card is held up too long in any column, everyone will be able to see that on the visualization board, allowing team members to identify any tasks that are taking longer than expected.

The Kanban Board

For any one large project, all the cards start on the far-left column, the To Do, or Backlog, column. A board typically consists of six to eight columns designed to fit the team’s needs. It could consists of the following categories of columns— 1) Backlog/To-Do, 2) Develop, 3) Develop Done, 4) Test, 5) Test Done, 6) Deploy—but also could have entirely different names.  The cards are never “pushed” onto any team or column, meaning when one team finishes a task, they don’t push the card onto the next team as it may be busy with other cards and have no time to take on a new one. Instead, the team that completes a task might put it in its Done column. Then, when the following team feels ready for it, it can pick up the card and begin the tasks listed on the card. For example, for the categories listed in Fig. 2 below, the developers would move a card they just completed into a Developer Done column. That way, when the testing team is ready, it can pull the card from the Developer Done column, put it in the Test column and start work on it.

Limits

Everyone knows how it feels to have too much work pushed upon them when they already have too much work on their plate. To prevent these bottlenecks from occurring, Kanban has work-in-progress (WIP) limits. Collectively, the team decides how many cards can be in any one column at any one time. The team members may decide there may only be five cards in the Developing column and four cards in the Testing column.

You’ll notice in the board above in Fig. 2 that even though Card 7 and Card 8 are in the Dev Done column, the testers are not going to touch that card because they already have four cards in their column. And as stated above, this project team set a WIP limit of four cards in the Test column. Not until the testers have only three cards in their column will they pull a card from the Dev Done column.

Now, what if the testers have completed all their cards, there are no cards in the Dev Done column, and there are still five cards in the Dev column? Will the testing team just sit around and wait for a card to come their way? No. Someone from the testing team would help the developers until it completes a card and moves it to the Dev Done column. At that point, the testers would begin working on the card. This is the beauty of cross-training and having a DevOps team that works together to solve problems. The project team continues to work this way until the project has been completed.

A Collective Leadership

In Kanban, there’s no “master” or one person in charge of ensuring everything runs smoothly. The team is collectively responsible for collaborating and delivering the tasks on the board, and for deciding when they are ready to package up the completed items for release. All team members should have a good understanding of Kanban skills and optimizing the system. They can become proficient in adopting the practices by taking a Kanban workshop.

Below are six core Kanban practices:

1. Visualize the workflow. The Kanban board helps people visualize work and the process it goes through. So each team will have a written or visual process of what the team must do for any specific work item.
2. Limit work in progress. Establish limits to the work you have in progress to prevent bottlenecks and limits to guide when to start new items. By limiting work in progress, you encourage your workforce to finish work at hand before taking on new work. This smooths the workflow for the team and helps them deliver items more frequently once a specified number of items have been completed.
3. Manage flow. Kanban helps your team analyze the system and make adjustments to improve flow to reduce the time it takes to complete each piece of work. The flow of work should be predictable. 
4. Make process policies that are clearly defined, discussed and published so the team understands and can achieve its goals.
5. Get feedback from stakeholders so you can deliver your items to your customers in the shortest possible time.
6. Collaborate continually. Implement changes based on feedback and metrics.

Kanban has become so popular that it is now used throughout business lines as well as in software development. While Kanban is easy to understand, it’s difficult to put into practice. Developers, testers, and project analysts may want to consider learning more about implementing Kanban to increase productivity and improve efficiency.