I'll briefly descibe the differences between the two and how I think it would matter for us. I will actually not try to be objective but instead say exactly what I believe.
I'll bring up one topic where there's differences and outline the two and what I believe is the best option for the Plejmo team.
This is just personal opinions and does in no way reflect anything. It's based on my understanding and what I've read.
Limits by time (sprints are for example 2 weeks long).
Limits by items per workflow states (for example max 4 items in in progress).
I believe this is the trickiest one to choose between. They're both two very reasonably ways to go with people having used both successfully.
I personally vote for the Kanban approach because of a few reasons:
- There are predefined activities that needs to be carried out when doing Scrum
- There are predefined roles that needs to exist when using Scrum
- Kanban simply approaches the problem of "a tool to handle work", while I believe scrum tackles the more broader problem "a tool to handle a team"
These are examples of values that exist by default. Of course for example sprint lengths could be added to Kanban if so desired.
- Average Cycle Time (how long does it take for an item to reach done when it enters the ToDO)
- Average Lead time (how long does it take from task creation until it's done)
- WIP limits in different columns (how many items can stay in "todo")
- Length of Sprint
- Average velocity
I don't think I have a strong oppinion at all on this. I've worked with scrum before but never gone all-in with Kanban, I think it would be really nice to try, especially since we're a small team and I don't think we're really in need of all the things that Scrum prescribes until we feel the need for such things.
None
- Retro
- Estimate
- Prioritizations
- Standup
- Burndown chart
Before we feel the need for them, I'd really like to avoid creating more activities. The good thing is that both of these aren't exclusive. So if we do Kanban, we can have Standups without saying that we're doing scrum. Adding isn't a problem, removing is however.
That why "Scrum-ish" is such a normal thing.
Should aim towards having work items that are similar sizes to each other. This improves the average lead time measurement and makes it less volatile.
Items should always be smaller than 1 sprint. All work should be able to be complited within one sprint.
Persistent
Reset at every sprint start.
Scrum effectively priorities when a new sprint starts and items are put into the sprint.
Kanban prioritizes whenever resources are made available.
- Lean & Agile
- Pull scheduling
- Limit WIP (different ways though)
- Transparent
- Focus on releasable software
- Break work into pieces
- Continously improve
- Require DoD
Kanban can be considered a "newer" approach to development.
Visualizing Scrum work: Burndown for Trello
Visualizing Kanban work: Screenful
Another visualizer: Corello