This is the first time in the history of my blog that I share the thoughts of a guest blogger. I introduced Kanban to my friend Peter (@keksz_i on twitter), who is very exited about Kanban and eager to learn more about it. Unfortunately, he had to participate in a less successful planning meeting…
The Time-box Issue
I just recently got familiar to Kanban – thanks to Zsolt – and I’ve started digging myself deep into Lean thinking. As a progress, day by day I am realizing more and more about the drawbacks of Scrum during my work. Hereby I’d like to share some of these small but rather important experiences.
We were at a planning team meeting. Our team was expected to commit 22-24 story points, based on the team’s velocity. We’ve already selected 18 story points of high priority stories from the backlog, but there was another 8 pointer “must to have” high priority story. Obviously, that could not fit to the sprint, as we would had 26 points with the 8 pointer. All other stories had lower priorities or they were not even estimated. How shall we proceed in that situation? We had a customer pressure to deliver to that story as well, but we could not, as it was a very high risk that we are not going to finish it by the end of the sprint. Basically we were in a time trap indicated by the iteration.
There were two possible solutions. One of them is to look after smaller stories from the backlog and fill the gap with them. Unfortunately, we haven’t had them. Even if we had had other stories to take, that solution wouldn’t been effective. Doing low priority things (stories, fixing low priority bugs, technical depth) just to fill the sprint instead of doing the real important jobs is really a waste. We definitely should not have done that.
We went for the second option: splitting the 8 pointer story to smaller stories. We were able to split it into two 3 pointer and a 5 pointer story. The first was a kind of preparation story for the epic with no testing effort. The other 3 pointer and the 5 pointer were the actual implementation stories including testing. By doing the splitting, we were able to commit to the two 3 pointer stories, having 24 points to work on in the current sprint and most likely having the remaining 5 pointer story in the next sprint. This looks much better for the first glance, but if we have a closer look we can realize that there is a huge waste. We had to do an estimation session to so the splitting, we doubled the testing effort where obviously we had overlaps and we had to prepare and demo it 3 times for the customer. In fact, the estimation numbers are also reflected the waste, as the overall complexity of the original epic became 9.
Using Kanban, all of these wastes would not arise at all. In Kanban, there is continuous delivery, there is no time box to fit. In Kanban, we would just pull the 8 pointer story, implement, test and deliver it at once. Without extra estimation sessions, without testing and demonstrating a half-functional story, without waste.
<div class="related-articles"><h5>You may also find interesting:(View all posts)</h5><ul><li>Introducing the Expectation Line in Scrum</li></ul></div>
comments powered by Disqus