Kanban : Changes

We looked at what has changed in Kanban in the previous post. Let us look at those changes and viewpoints in detail.
#1. Time-Boxed Development is Out
When i transitioned from a Traditional approach to an agile approach (Scrum), the most important thing we all learnt is following Time-boxed iterations.
Let us look at the benefits of Time-boxed iterations.
1. Shorter Feedback Cycle. Other than feedback, In an outsourced environment, demos at the end of every 2 weeks (my iteration cycles were 2 weeks) provided lot of value adds. My clients saw the productivity every 2 weeks which gave them confidence, which in return helped us build the trust.
2. Software Development is also like music (based on Rhythm). When we all know how much we could achieve in a specific period (we will have our Rhythm).
3. Estimating items for a short period of time was easier than for a longer period.
And now you are saying Time-boxed Development is out? You must be crazy.
You’d still find the “heartbeat” of regular cycles in a team following Kanban — at least if they’re doing agile right you should. The only difference is the cycles aren’t used to plan and commit to stories any longer.
Why so?
1. First, there are quite of bit of overheads (as seen by people) for every sprints.
2. The other thing which i found is a problem is that writing stories which can be estimated. Atleast to my knowledge, i have not seen Product Owners following all the INVEST principles and writing stories.
In reality, Kanban introduces the term cycle periods (instead of sprints/iterations).
Differences between Iterations and Cycle Periods:
1. You do not use the cycle period for planning, estimating and committing stories.
2. Cycle Times are Scope Bound (similar to the Spiral Development Model) rather than Time Bound (XP/Scrum).
#2. Stories are Larger and Fewer
Scrum recommeded us to write smaller Stories (i am sure most of us has read this book User Stories Applied from Mike Cohn which talked about the Invest Principles).
There’s a lot of good reasons for wanting to write smaller stories.
1. It’s a lot easier to estimate a story that’s small — which can lead to more accurate estimates, and better predictability.
2. It’s easier to plan with smaller stories.
With big stories
a. Stories that might take weeks for a developer to implement
b. It becomes difficult to plan a development time-box — particularly when the iterations are only a couple of weeks.
c. It seems that only a couple stories fit
d. There’s often room for half a story, but how do you build half a story? Splitting them into smaller stories makes it easier to plan those time-boxes.
But nothing comes free in this world. If you write smaller stories, product backlogs become bigger and more difficult to manage. If you analyze the Product Backlog, it can easily be into the range of hundreds of stories. Prioritizing, managing, and planning with this sort of backlog will become very difficult.
Product owners are often asked to break down stories to a level where a single story becomes meaningless (Business Stories -> Developer Stories -> Tasks). To keep track of what’s meaningful (to them and other stakeholders), one often need to build a track of how many stories per feature etc which becomes a maintenance nightmare.
Hence, the notion of stories are larger in Kanban.
This works well if you are not having distributed development teams. But if the teams are distributed, having an Epic Story has its own disadvantage (Requirements understanding, communication overhead etc..)
#3. No Estimation
Agile methodologies (Scrum) introduced a new way of estimation using Story Points and new way of communicating how much can be achieved via Velocity.
If we go back to the basics, the main reason why we estimate is to be able to plan releases and to be able to prioritize.
1. When we know the size of a feature, it’s far easier to prioritize based on how much one can accommodate.
2. Velocity helps in planning how much can be delivered in a Release.
3. Task based estimation at the sprint level helps in deciding the appropriate load (Resource Levelling) and helps the teams to commit on what’s possible.
Now, we are saying that there will be no estimation.
I was talking to a colleague (who moved to Kanban) sometime back about the estimation and he mentioned that most of the times we were not able to meet our own estimates and sprint planning every 2 weeks is not helping them scale.
One reason, for the above is that the features or stories are not estimable. Team is not able to exactly decide. And since, we do not have a time bound sprints in Kanban (Its Scope bound), there is no point in estimating. It works in a Pull model, where the team members completes the task and moves to the next one.
So, the next question comes is do we still need to plan releases and prioritize? Well, yes of course. So Estimating the product backlog with a size will definitely help the release planning team to decide how much can be achieved. We may not use the velocity, but like use some estimation principles to know what can be achieved.
How about task level estimates? No. Since there is no commitment on the tasks in a specific duration (Iterations), there is no need to do this.
Okay, will there be any disadvantages? Well, we will look at it at a different section
#4. Velocity is replaced by cycle time
I am not going to spend talking too much about this. I will talk about the reasons later in a different post.

Reference URL:
Kanban Development Oversimplified
Kanban Estimates
What will Kanban bring to your offshore Projects?
Happy Reading!!!


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s