When we talk about project management, the words “Scrum” and “Kanban” are increasingly recurrent and sometimes are confused.
With that said, we notice the meaning of each term and its main virtues to avoid misunderstandings and enable you to make the best choices for your team of developers.
Agile methodologies emerged when the waterfall method was not corresponding well. The simplest and most valuable methods of this new philosophy are Scrum and Kanban.
But Scrum and Kanban have different goals and missions to help you increase your team’s performance and productivity. This article will lead you to differ between both actions.
How Scrum looks like for a project management team
First of all, we need to claim the importance of team engagement. Without it, you cannot succeed. This engagement is important because, in Kanban, each employee is responsible for keeping the panel always up to date.
First, we start by moving more towards the Scrum side, where we need to take some essential steps. You must define your team, choose the Product Owner (person responsible for the vision of what will be delivered in the project) and the Scrum Master (who will guide the team).
With scrum, your team promises to ship some valuable increment of work by the end of each sprint. Scrum is built on empiricism, focusing on small increments of work that will help you learn from your customers and better inform what you do next. Here’s how it breaks down:
The rise of Scrum
Scrum moves fast, with sprints of two to at most four weeks with clear start and finish dates. The short time frame forces complex tasks to be split into smaller stories and help your team learn quickly. A key question is this: Can your team ship useable code that fast?
Sprints are sprint planning, sprint review, and retrospective meetings and peppered with daily scrum(standup) meetings. These scrum ceremonies are lightweight and run continuously.
What are the main roles in Scrum?
Nowadays, it’s common to have some releases in Scrum, but it’s long been a best practice to release at the end of each sprint. Teams set a goal for each sprint and they either approve it for release in the sprint review meeting or not.
According to Atlassian, Scrum has three clearly defined roles.
- The product owner advocates for the customer manages the product backlog and helps prioritize the work done by the development team.
- The scrum master helps the team stay grounded in the Scrum principles.
- The development team chooses the work to be done, delivers increments, and demonstrates collective accountability.
Scrum Metrics
Velocity—the number of story points completed in a sprint—is the central metric for scrum teams. It guides future sprint commitments, or how much work the scrum team takes on in future sprints. If the team completes an average of 35 story points per sprint (Velocity = 35), it won’t agree to a sprint backlog that contains 45 points.
Teams strive to not make scope changes during a sprint. Scrum teams sometimes get feedback and learn that what they’re working on isn’t as valuable to the customer as they thought.
In such cases, the scope of the sprint should change to reflect the importance of shipping value to the customer first and foremost. During the sprint retrospective, scrum teams should discuss how to limit change in the future, as changes put the potentially shippable increment at risk.
Metrics Daily Scrum
From there, we will have Daily Scrum, a daily meeting between the team and the Scrum Master. It’s a quick meeting just for everyone to answer three questions: “What did you do yesterday?”, “What are you going to do today?” and “What problems did you encounter?”.
Remember that they are short and quick answers, but that it helps the whole team to know where they are in the Sprint. With this, the Scrum Master will be able to see if all tasks need completion on time. And of course, he is the one who will solve any obstacles he may have on the team.
After the Sprint period (1 or 2 weeks), you need to carry out the Sprint Review. It is the meeting where the team presents what has evolved during the Sprint, being able to present only what they manage to put on the board as “done”, that is, the task needs completion.
Finally, we have the Sprint retrospective, where those involved can assess everything that happened, such as lessons learned, what didn’t work. It is a feedback meeting to improve the process, thus improving future Sprints.
How does Kanban work?
Kanban is great for teams that have lots of incoming requests that vary in priority and size. Whereas scrum processes require high control over what is in scope, kanban lets you go with the flow. Let’s take a look at the same five considerations to help you decide.
Kanban is based on a continuous workflow structure that keeps teams nimble and ready to adapt to changing priorities. Work items—represented by cards— are organized on a kanban board where they flow from one stage of the workflow(column) to the next. Common workflow stages are To Do, In Progress, In Review, Blocked, and Done. But that’s boring.
The best part of Kanban is making custom columns for how your team works. Our board helped us learn that we ship about one piece of content per week, and where our bottlenecks are.
Kanban Methodology
In Kanban, you can release updates whenever they are ready, without a regular schedule or predetermined due dates.
In theory, kanban does not prescribe a fixed time to deliver a task. If you finish the task earlier (or later), you may release it without having to wait for a release milestone like sprint review.
The whole team owns the kanban board. Some teams enlist an agile coach but, unlike scrum, there is no single “kanban master” who keeps everything running smoothly. It’s the collective responsibility of the entire team to collaborate on and deliver the tasks on the board.
Kanban Measurement
There are at least two important metrics for Kanban boards: Lead time and cycle. The average amount of time for a task moves from start to finish. Improving cycle times indicates the success of Kanban teams.
The Cumulative Flow Diagram (CFD) is another analytical tool for kanban teams to understand the number of work items in each state. CFDs help identify specific bottlenecks that need better throughput.
Another way to deal with bottlenecks is through Work In Progress(WIP) limits. A WIP limit caps the number of cards that can be in any one column at one time.
Workflow with Kanban
You can change a Kanban workflow at any time. New work items can get added to the backlog and existing cards can get blocked or removed altogether based on prioritization. Also, if the team capacity changes, the WIP limit can be recalibrated and work items adjusted accordingly. It’s all about being flexible in Kanban.
Access the best Scrum and Kanban features of GitScrum!
GitScrum brings you the right Scrum and Kanban tools to help you organize and create more productive tasks in your team!
Sign up now and have the best Scrum and Kanban tools for your team!