This is the first follow-up post on the transition to Kanban for one of the teams I’m involved with at the moment. The first post can be found here: Moving from Scrum to Kanban… yay or nay?
Since we also did a merge of two different teams at the same time as the transition to Kanban, it is quite hard to predict how the data will look.
What we can do is look at the data for the two teams before the merger, make some assumptions, and then make an educated guess about what we can achieve.
If we start with team X, they had a weekly throughput of roughly 8 to 20 tasks. Looking at a monthly basis this was between 25 to 40 tasks. So quite the spread in throughput, but nothing strange when talking about development work.
Looking at team Y, their weekly numbers swivel between 5 to 19 tasks and monthly between 17 to 40 tasks.
A task in this case represents a Post-it on the board, this could be anything from new development to a bug, or simply just perform a test session together.
If we simply add the two teams throughput together we should end up with something like 15 to 39 tasks/week or 42 to 80 tasks/month. This gives us a ballpark number to play with. But for us who have worked with teams before know that you simply can’t expect the throughput to be the same when you change the team dynamics. Also, this time around we are not interested in increasing the throughput of tasks, we are interested in increasing the throughput of stories.
Unfortunately we haven’t measure on story level before for certain reasons. But, fortunately, we have seen that a story in our environment, has in general 8 tasks attached to it. With this simplification we can assume that we will have a throughtput of (15/8 to 39/8) = 2 to 5 stories/week and (42/8 to 80/8) = 5 to 10 stories/month. And to simplify even more, say we are just interested in the monthly throughput. By looking at the above numbers, we should be getting 5 to 10 stories/month.
But it is not as simple as that is it?
Well, first of all, all tasks that are performed by a team is not related to the stories that are prioritized. There might be old bugs, refactoring, work with the build server, and so on. In our case, roughly 25% of the work done during the measured period referred to above can be classified as “other”, i.e. not related to any story.
We also need to take into account the change in team dynamics when putting a new group of people together. Based on my observations in the environment we are working in, I don’t foresee this to be affecting the throughput in a negative way. However, we won’t see any significant increase in the near future without coaching and speeding the teambuilding process along.
What do we think we can achieve?
Based on the observations described above, and by simply merging the two teams and move over to Kanban, we should see a throughput of 10 to 20 issues/month and 3 to 7.5 stories/month. This might seem like a very unpredictable number, but this is what can be said based on the data we have and the assumptions we have made.
So how does it look right now?
Currently we have roughly 3 weeks of data with the new setup. This means that we need extrapolate data in order to get an indication of how the first month looks.
Seeing as we have managed to get 5 stories done i the 3 weeks that have passed, this translates to a throughput of 6.67 stories/month, which is within our assumptions.
Issues on the other hand looks a bit more interesting. Here we are seeing a steady increase from week to week, looking at 7 then 9 and now 17, which would, without taking the steady increase into account, result in an issue throughput of roughly 40 to 50 issues/month. This is way above anticipated, at the same time the story thoughput is on the lower half of the estimate.
What does this mean?
One observation made is that most of the team members feel more comfortable in working on stand alone items, and the issue lane on the board has this characteristic. This was completely anticipated, but something I felt we needed to find out by collecting the data and have something concrete to present.
Another aspect of this might be that the stories that are prioritized aren’t pitched in a way that makes everyone feel the importance of them.
What happens now?
At the end of this week we will look at the data and have a discussion around the flow on the board. I see a few changes that I think will improve the focus on stories and shift the throughput to favor those. I will however give the team the room to come to their own insight.