Kanban VS Scrum: How do these Agile Frameworks Differ?

The idea of adopting an iterative development approach has been gaining grounds in the software industry. Agile methodology for project management, which was introduced back in 2001 has transformed the way software development companies deliver the product throughput. The Kanban Vs Scrum tilt has been going on for quite a time now. Here are the key differentiators that hold them apart.

Agile is a set of goals, principles, and practices that uncovers better way of developing a software. Agile methodology favors:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

These values and principles espoused from Agile were underpinned into some of the Agile software development frameworks, such as Kanban, Scrum, Lean, XP.

In the later segment, we will understand two of the most popular Agile frameworks to acknowledge their benefits in a software development cycle. Kanban Vs Scrum; let’s start the comparison.

Scrum: A Structured Agile Approach

Scrum is an iterative and incremental approach to agile software development. In Scrum methodology, a Sprint is the basic unit of development. Each sprint starts with a meeting, wherein tasks for a sprint are identified, along with an estimated time to commit the sprint goal. A sprint ends with a review or a retrospective session, where the progress for defined tasks are reviewed and lessons for the next sprint are identified. At the end of each sprint, a finished portion of a product is created by the team.

In an Agile practice for software development, each iteration involves a team working on a full development cycle-involving planning, requirement analysis, design, coding, unit testing, and acceptance testing. If in a scrum sprint, all of the software development phases (right from requirement understanding to acceptance testing) are performed, the scrum sprint can be considered to be corresponding to Agile iterations.

There are 6 types of meetings in scrum:

• Daily Scrum / Standup
• Backlog grooming: storyline
• Scrum of Scrums
• Sprint Planning meeting
• Sprint review meeting
• Sprint retrospective

Scrum Cadence:

Scrum sprints generally have a time span of two to four weeks, with a clear start and finish dates. The short time frames ensure that complex tasks are split into short stories, enabling teams to learn fast and deliver expected outcomes to maintain project agility. Sprints are punctuated by ‘Inspect and Adapt’ ceremonies where the sprint tasks are reviewed through daily scrum (standup) meeting.

Core Roles:

a. Scrum Master,

b. Product Owner,

c. Development Team

Ancillary Role: These roles in Scrum teams don’t have a formal role and generally have infrequent involvement in the Scrum procession but nonetheless, they must be taken into account. viz. Stakeholders, Managers.

Release Methodology:

At the end of each review, the team reviews the increment (the end-product of a sprint) through a demo and either approves the release or declines it. A sprint should end with a shippable increment.

Key Metrics:

Velocity is the central metric to measure a scrum success. Velocity, which is counted through Story Points guides future sprint commitments or how much work the scrum team commits to. Story points rate the relative effort of work in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, instead of days, dates, or hours.

Kanban: A Continuous Improvement Approach

Unlike Scrum, Kanban is not a software development methodology. Instead of defining a roadmap for development, it allows visualizing and improving the ongoing tasks.

The Kanban approach to streamline development uses Kanban Board, which helps to visualize tasks, limit work-in-progress, and maximize efficiency or manage flow of development. The Kanban board use cards, columns, commitment, and delivery points to keep the team members informed about the work progress, so that teams commit to right amount of work and get it done.

5 major elements of a Kanban Board includes:

Visual Signals: Stickies, tickets, and other visual cards are an important part of a Kanban board. The Kanban teams write one user story on each card, which gives all team members an idea that about what the team is currently working on.

Columns: Each column on a Kanban board represents a specific activity, which all together compose a workflow. These cards flow through a workflow, which can be as simple as a “To-Do”, “In Progress”, “Complete” or could be complex as well.

Work in Progress (WIP) Limits: WIP limits are the maximum number of cards that can be moved to a column at a given time.

Commitment Point: The backlog is the place where the teammates put their ideas for project and usually pull the tasks from. The commitment point is the moment when an idea is picked by the team and either an individual or more starts working on it.

Delivery Point: The delivery point marks the end of Kanban workflow. The goal of a team is to move cards from commitment point to the delivery time, as fast as possible. Usually, the delivery point is, when the product is delivered to the customer.

Kanban Cadence:

Kanban is based on continuous workflow structure, wherein the team picks and prioritizes tasks according to expected lead time (from commitment to delivery point), complexity, availability of a team member etc.

Roles:

The entire team involved in software application development owns the Kanban board. There is no Kanban Master involved (like the Scrum Master in Scrum) to ensure that things move from one stage to another smoothly. Instead, the team is responsible to collaborate and finish the tasks listed on board.

Release Methodology:

There is no predefined time to complete and deliver a task. At any point, if a task is completed, it can be released, without having to wait for present release milestone.

Key Metrics:

Cycle Time: This is the average time taken to move a task from start to finish line. Continuous improvement in this time means increased team efficiency.

Cumulative Flow Diagram (CFD): This is an analytical tool that helps Kanban team to understand the number of work items to be added in each state.

Kanban Vs Scrum: Key Differentiators

Scrum is an Agile framework that incorporates accountability, inspection and adaptation, and transparency as its fundamental pillars. The three roles- Product Owner, Scrum Master, and Development Team takes accountability of their jobs to ensure that everyone knows what had to be done by whom. Scrum is focused on project delivery and is thus best suited for complex projects with strict deadlines.

Kanban on the other hand focuses on managing workflow of a project, rather than its delivery. That is why, Kanban needs more discipline in team for project success.

Kanban Vs Scrum: Which Agile Framework to Choose?

Scrum is an empirical framework optimized for delivering Software, while Kanban is an empirical method of optimizing any existing process. The choice depends upon the nature of the project. Choose Scrum if your project demands to deliver value to the client on a continuous basis, because Scrum provides a highly prescriptive way in which work gets completed. Since Kanban can be customized to run as per your workflows, go for Kanban if you value flexibility more than predictability.

Originally published at insights.daffodilsw.com.