Jira
monday.com
Scrum and Kanban have certain similarities. Both are transparent, break down work, limit WIP (albeit differently), and focus on delivering releasable products early.
In practice, however, they are quite distinct from one another. The differences between the two approaches are reflected in the software and tools that support these development frameworks.
The main differences between Kanban and Scrum
Let’s take a closer look at what sets these two prominent work management frameworks apart from one another.
Please note, these are not the only defining factors of the methodologies. I am consciously limiting the differences to the context of using Scrum and Kanban in Jira.
Iterations
Scrum works in time-boxed iterations or Sprints. Every Sprint has a goal, a beginning, and an end. The team will deliver an increment or, according to the Scrum Guide, a stepping stone towards the Product Goal. In simpler terms, you will have a “Done”, useable, and potentially releasable product at the end of every Sprint.
Kanban, on the other hand, avoids forcing things into time-boxes. It supports a continuous flow of work where the tasks are moved to “Done” when they are completed.
Push VS Pull
The Push-Pull strategy has several definitions. However, the basic gist is that Pull systems initiate development as a reaction to current demand, while Push systems trigger development independently or with anticipation of future demand.
By this definition, Kanban is a purely Pull system. The philosophy behind the framework allows team members to pull their next task from the backlog or the “To Do” column on the board once they have completed the previous work.
Scrum can look like a Pull system on the surface as the team is “pulling” the tasks from the backlog into the Sprint, the fact that you plan Sprints in advance based on an estimation of productivity per a set time frame makes it a Push system.
Estimations
Estimations are an integral part of the Scrum framework. The items in the backlog are continuously refined. The backlog refinement sessions take place in set intervals of time, usually in the middle of an active Sprint. Product Owners, Product Managers, and the team review and prioritize tasks during this session. User Story estimations are used to predict the effort that will be required to complete the work.
Kanban does not require estimations. Some teams still prefer to estimate tasks. However, the methodology itself is primarily reliant on flow metrics like WIP, Cycle Time, and Throughput for predicting deliverability.
Which board is best for your project?
“Assume the Cow is a Sphere…” – An old physics joke
The spherical cow is a humorous metaphor for highly simplified scientific models of complex phenomena.
This metaphor can go way beyond physics, however. Trying to guess which methodology will fit with your project, management style, and culture is – in essence – assuming a cow is a sphere for the sake of simplicity.
For instance, the iterative nature of Scrum is highly reliant on accurate, proactive planning and typically fits projects that demand quick delivery and are greatly impacted by feedback. Startups, early-stage product development, or development of an MVP usually fall into this category.
That said, having time-boxed iterations can be extremely stressful for teams who have yet to develop good engineering practices and finetune continuous integration.
The same can be said about Kanban. By nature, this approach seems like a perfect fit for ongoing processes where operations are done one by one based on priority. Several prominent examples may include support teams, HR, marketing, procurement, operations, and software products in support mode.
The process may seem much less stressful than a time-boxed Sprint. At least on paper. In reality, however, Kanban requires much more upfront management. Your team needs to develop functional way-of-working policies that help everyone deal with various situations.
For example, everyone on the team needs to know what to do when a new ticket appears in the ToDo column while everyone is at their WIP limit. Every team member needs to know when to “pull”. Everyone should be on the same page regarding the Definition of Done, Definition of Ready, Due Dates at Risk, etc.
You know your team better than anyone, and thus, ultimately, the decision between Scrum and Kanban is up to you.
Still, I’d advise relying on Scrum in cases when you work in iterations and rely on continuous feedback. This is very typical for Startups or young products. Kanban, on the other hand, is best suited for continuous ongoing work like company operations, product marketing, or product support.
How do Scrum and Kanban projects differ in Jira?
The most on-the-nose differentiator between Scrum and Kanban projects in Jira is probably the backlog functionality. However, there are many other ways in which the different project templates support their respective methodologies.
Backlog
While you can add a Product Backlog in a Kanban board from the board settings, it probably will not serve any practical function other than to keep the list of all the tasks from the board.
The backlog functionality in a Scrum project is a different beast.
For starters, you have not one but two (and potentially more) backlogs. One is the Product Backlog, and the other is the Sprint backlog.
- The Sprint Backlog consists of a set of user stories or tasks that the development team commits to completing within a specific sprint or timeboxed iteration. It is a subset of the product backlog and represents the work sprint planning for that particular sprint.
- The Product Backlog contains a prioritized list of all the desired features, enhancements, and bug fixes for the product. It represents the complete scope of work that needs to be done over multiple sprints.
Furthermore, the Sprint Backlog functionality in Jira supports the framework by forcing you to fill out the Sprint goal, the time-box, and the start and end dates at the beginning of every Sprint.
Tip
Jira allows you to create multiple Sprints in the backlog. You can use this feature to better categorize backlog items too. For instance, you can separate technical debt, bugs, feature requests, etc., into several categories for comfort and ease of future planning. Our team has made it a rule to pull out at least two tickets out of the Tech Debt backlog during every Sprint Planning session.
Limiting WIP
Both Kanban and Scrum are designed in a way where people are not forced to juggle multiple tasks at once. But they approach imposing a WIP limit quite differently, and Jira reflects this.
Being driven by the Push principle, meaning tasks are added to the Sprint in advance, Scrum limits sprint scope through planning and estimations. The user stories are assigned Story Points that are being burned during a single Sprint. The team can then use this data to predictably plan the scope of the next Sprint and “push” a limited amount of work into progress.
This is why issues in a Scrum project will have a dedicated field for adding Story Points.
The Kanban methodology limits WIP differently. It does not rely on pushing a predefined amount of work. Therefore, there is no need for features like the Story Points field.
Instead, a Kanban project is reliant on the board itself. For starters, seeing when issues pile up in a single column is quite simple and intuitive.
The issues themselves will have an indication of “aging” or the amount of time a specific task has remained in one column.
In addition, you can access the Average Age Report from the Reports tab on your board. As the name suggests, this report shows the average age of unresolved issues for a project. Your team can use this data to design a way to efficiently limit WIP.
As for the process of actively limiting WIP itself, you can go to your board settings > columns and manually limit the number of items that can be in a specific column at a given moment in time.
Reporting
Given the difference in the approach to planning and the flow of work, Kanban and Scrum projects will require a different set of reporting tools. Luckily, Jira provides them handily tucked into the reports tab.
In fact, the reports that are available in Jira are probably excessive. I don’t know anyone who would use all of them in their work. That’s why I’ll stick to the ones that are specific to the Kanban and Scrum methodologies.
| Scrum | Kanban |
|---|---|
| Burndown Chart: Tracks the remaining story points in Jira and predicts the likelihood of completing the Sprint goal. Sprint Report: Analyzes the work done during a Sprint. It is used to point out either overcommitment or scope creep in a Jira project. Velocity Chart: Shows historical data of work completed from Sprint to Sprint. This chart is a nice tool for predicting how much work your team can reliably deliver based on previously burned Jira Story Points. | Cycle Time Report: Helps understand how much time it takes to ship issues through the entire workflow from ToDo to Done. Average Age Report: Shows the average age of unresolved issues in a project or filter. Great for pinpointing bottlenecks. Cumulative Flow Diagram: Shows the change in statuses of issues over time and helps identify bottlenecks based on historical data. |
Note
Follow these steps if you don’t see the reports tab:
1. Select the Add View option (you’ll need to request help from someone with project admin permissions if this option is not available).
2. Select the More Features option.
3. Find the Reports option and toggle it on.
Features that are exclusive to Scrum and Kanban Jira Projects
| Scrum | Kanban |
|---|---|
| - Backlog with Sprints - Story Points field - Scrum-specific reports like the Burndown or Burnup Charts - Insights | - WIP limits for columns - Tickets go directly into the board unless the backlog is set up - Epics can be shown on the board as cards - Kanban-Specific reports like the Average Age Report |
Bonus: Can you Switch between Kanban and Scrum projects in Jira?
Technically, Jira does not allow you to switch between Scrum and Kanban project templates. That being said, there are several things you can do, depending on the type of project that you are using.
- A Scrum project in a Team-Managed Jira instance will allow you to toggle Sprints on and off. This will essentially give you the same view as you would have had with a Kanban board. You can do so from the Add View option.
- On the other hand, you can create a new board based on an existing Scrum or Kanban Board if you are using a Company-Managed project.
- Create a new board from the board menu.
Pick the type of board you’d like to create.
Choose the Board from an existing project option.
Select the Project (board) you’d like to copy into a new board and create it.
That’s it. You will now have a new Scrum/Kanban board that contains the tickets from the original board.
Final thoughts
You have the most intimate understanding of your team, giving you the ultimate decision-making power between Scrum and Kanban. This article aims to assist you in comprehending how a work management solution like Jira can align with your strengths and values. I sincerely hope this information enhances your understanding and aids you in making an informed choice.
