![]() |
| Kanban - Laitkor |
Agile embarks with the initial requirement rather peeping into far end products. Team entirely focuses on the iterative working models commonly used to be a matter of week or a month rather than peeping inside the far end results.
Several methodologies were introduced which implement Agile framework, two are most popular among them i.e. Scrum and Kanban. Now the question arises, which one is the best?
This can never be replied in yes or no, as both carry certain advantages and certain disadvantages at different stages. It’s imperative to analyze the kind of project and end user’s demand drastically. Let’s have a brief idea on both so as to ensure their compatibility with your requirement to some extent.
What is Kanban:
According to the Kanban blog, “Kanban is a technique for managing a software development process in a highly efficient way. Kanban underpins Toyota’s ‘just-in-time’ (JIT) product system. Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied.
What is Scrum?
Scrum emphasizes on face to face communication among the team on regular interval, it embraces any emerging changes at any course of development. At the end of every sprint feedback is taken and process is iterated if required. During each sprint, the team will use visual artifacts like task boards or burndown charts to show progress and receive incremental feedback.
When to use Kanban:
- You need to add stories or change sprints on the fly
- Iteration is not required.
- Estimation isn’t essential.
- There is ability to deliver any time.
- Continuous improvement is already emphasized
- Solution is under consideration and not very sure.
- Continuity of the delivery is required.
- System is not complex and easy to understand.
When to use Scrum?
- The project requirements may change at course of development.
- Continuous feedback is required
- You have to think about the complex problem as you might not have done before.
- Release date is not committed as fixed.
- Project team wants independence to work.
- Modules are required to be delivered on regular basis.











