Kanban, WIP and Happy Stakeholders
Bart has been in ecommerce for over 20 years, and can’t imagine a better job to have. He is interested in all things agile, or anything new to learn.
Many of the teams I work with have moved from a somewhat traditional, "vanilla" Scrum-based approach for sprint planning to one that is more Kanban-style. To the untrained eye, these methodologies seem similar enough to maybe not even be noteworthy. Both are first-order Agile processes, and they espouse mostly the same principles, so changing from one to the other is often a non-event when it comes to people not involved in the daily operations of the team.
However, one of the primary differences turns out to be very impactful: the focus on mechanisms that specifically are targeted at limiting Work in Progress (WIP), which helps to make sure that stories are worked on through completion in the order that provides the most value.
A normal scrum planning process has the team adding a basket of user stories into the current sprint, based on the team’s velocity. For example, let’s say that a scrum team of six developers adds 12 stories into the current sprint, with the targeted outcome of completing them all by the end of the sprint. This kind of planning means that the team is tasked with completing all 12 items by the end of the cycle, and in whatever way they choose to self-organize to do so. As long as the team completes all 12 in the time allotted, all the stakeholders should be satisfied. The reality rarely…
Please log in or sign up below to read the rest of the article.
ADVERTISEMENT
Published at Thu, 28 Jun 2018 04:00:00 +0000
