Simplifying the Scrum Vs Kanban Dilemma
As a PM fresh out of Product School, I have battled with fully grasping the difference between Scrum and Kanban — well, not anymore. An awesome video I stumbled on via YouTube simplified it all to the teeth and I will be sharing what I learnt.
First, we should understand that both Scrum and Kanban are software development methodologies.
Secondly, Scrum and Kanban are PULL systems in the sense that both ensure work gets from the product backlog to the customer in the shortest possible time. PULL systems also help uncover “bottlenecks” in any product’s development process.
As product managers, it is our job to take input from customers and other stakeholders and organize the feedback into a prioritized list of features and user stories commonly referred to as the product backlog.
Now, everything that happens between the product backlog and the customer is what differencies Scrum from Kanban.
SCRUM
Scrum Teams work in a series of sprints (most commonly 2 weeks in length)
A sprint planning meeting usually preceeds each sprint.
Sprints are usually run by the SCRUM MASTER and attended by the product manager and the development team.
During the sprint planning meeting, they all select high priority items from the product backlog that the dev team believes it can commit to delivering in a single sprint (going with the plan above, we are saying a sprint of weeks).
For the next two weeks, the dev team will focus on working through the items on the sprint backlog.
During this time, any new requirements have to wait for the next sprint.
Scrum teams make use of a Scrum Board.
Now, each day during the sprint, there is a “Scrum Meeting”. This meeting does not usually last long (it should be a maximum of atleast 15 minutes).
The team usually discusses progress as well as identifies any “blockers” they may be experiencing.
At the end of the sprint, work completed during the spring is packaged for release.
Any incomplete items are returned to the product backlog.
A sprint usually ends with 2 important rituals:
- Sprint review: at this time, PMs demonstrate the new functionality to stakeholders.
p.s: stakeholders are usually people or groups of persons who have an interest in the product and its success, can influence product decisions or is affected by the outcome or deliverables from your work. Stakeholders are likely to be drawn from company executives, sales and marketing teams or operation and support teams. Any product’s key stakeholder in my opinion, will have to be the product owner but more on that later.
2. Sprint retrospective: this is an examination of;
- what went well
- what went badly
- what could be improved on
The sprint retrospective is very important because it ensures the next sprint is more efficient and effective than the last.
KANBAN
Kanban has no two weeks sprint nor does it have a sprint backlog.
Kanban is a continous process and its pull system happens in a different way via Work In Progress Limits
Each column on the Kanban board has a work in progress limit related to the teams capacity.
This means that a team with 2 devs would set a limit between two and four items (in most cases, the lower the better)
When the build of any column is empty, it is usually a signal to send another ticket into the continous process. So for example, if the doing column is moved to done, the to-do column is immmediately moved to doing.
Similarly, when the entire build is empty, it is a signal to the dev team to send another high priority item from the product backlog into the continous process.
Kanban replaces daily scrum meetings for standups and replaces demo’s for sprint reviews and retrospectives for sprint retrospectives.
At the end of the day, organisations flex the system and discover what works best for them.
If you liked this article and will like to watch the video, you are welcome.
You are free to look through my portfolio website, or just follow me on my social media handles via LinkedIn or Twitter.
