Planning in general - not just in software development - is not an easy thing. We have to know what to do next and have an idea when it will be ready. Although the former is harder the latter seems to be more problematic. We also struggled with it with my old team at Digital Natives. We had frequent and long planning meetings, and had rarely finished everything we had planned. So, we decided it was enough, and it was time to try something new. After about two months, we were able to give very accurate hour based predictions on spent time and delivery (lead time) with a quarter of the effort of our previous planning meetings.
We started a new board - not a Kanban board - where we collected the already finished work items:
As you can see this board had three different columns. Each column represented a T-shirt size: ‘S’, ‘M’, and ‘L’. When we set up this board we put all the work items we had into these columns based on difficulty. Our smart questions were: “was this work item hard to do?” and “was it harder than these work items in this column?”. With this approach we ended up with three columns and since we weren’t able to find right titles for the them we named them T-shirt sizes. We calculated the lead time and spent time using distribution diagrams for each, and wrote them on the board (you can see them on the next picture). At the end of each week, we recalculated and put them on the board in order to use always the latest data for our predictions. When a work item was finished we put it into its proper column.
When we got a new work item, we gathered around the board, and we tried to estimate the right difficulty for the new work. Then we wrote ‘S’, ‘M’, or ‘L’ on the card and put it on our Kanban board. During the daily meeting our product owner checked the new work items on the board. When he thought that an item would take too long - its predicted spent time based on its size was too much - he asked us to cut the work item into pieces or he reduced the scope just to let something hit the market sooner. Our weekly inflow was around 7 work items, we spent around 5 minutes on finding the right place for the card, so our planning effort was a bit more than half an hour. Before that we have never finished our planning meeting in under two hours. The other big gain was that we could get rid of Scrum sprints and could work continuously: the planning meeting wasn’t an obstacle any more.
After several weeks, we observed that our predictions were not as good as before. There were ‘M’ sized items that were finished sooner, and vice versa. After a retrospective meeting we concluded that some of our data had expired. We were getting better at what we were doing, learned a lot about the product, and did several minor improvements in the meantime, therefore our old data was no longer useful. So we introduced lines on our board. Each line represented a week, and the latest was on the top (it took about 5 minutes to shift the whole board down each week, so it wasn’t a big effort). When we were doing the planning we considered only the last three weeks.
Of course we were wrong several times. The note on the right shows a transformation from ‘S’ -> ‘M’. After a work item was finished we took it from our Kanban board and move it to the other board. When a work item took more time than we had originally predicted, we tried to find the right place for it. The work item above was predicted as ‘S’ but actually was an ‘M’, so we put it into the ‘M’ column. With this technique we kept our board up to date. Of course, if it was an ‘S’ but we predicted an ‘M’ we did the same routine. This ‘S’ -> ‘M’ marker became very helpful later. There is an inner voice that tells us “next time you’ll do better”, but this marker kept us from listening to it. If the new work item was similar to a card with ‘S’ -> ‘M’, we wouldn’t mark it as ‘S’ because we knew that we had problems with predicting similar work items before, so it became an ‘M’. Most of time we were right, and I’m still very happy about it, because we were making decisions based on data and not gut feeling. Moreover, we were also looking for certain keywords. For example, if a work item had the word ‘wizard’ in its description it couldn’t get into the ‘S’ column, ever. Even if it was a text change on the UI. We tried several times to finish a ‘wizard’ related work within ‘S’ scope, and we never succeeded. So, the minimum an ‘wizard’ work item could get was an ‘M’. And our product owner was okay with this (I guess he valued predictability and quality over speed).
You may wonder about a couple of things. First, why were we tracking both the lead and spent time? We were kind of working in a TTM (time to market) fashion so it mattered how much time we spent on this project during a week or a month, so the spent time was important. On the other hand we needed the lead time to predict when a work item could be delivered. We weren’t doing continuous delivery - we did continuous deployment - so it was good to know when we can deploy.
Second, what has happened to the architectural decision part of a planning meeting? During a typical Scrum planning meeting, the teams kind of make architectural decisions as well. We didn’t stop doing this. We changed our process so that we did this planning for each new work item when it could get into the ‘analyse’ phase (before implementation). So in general the time we spent on planning didn’t change much. What changed is the time we spent on a regular planning meeting, and we reduced some mura waste: we planned when it was necessary, and therefore we had fewer re-planning sessions than before.
And third, the environment. When we started to do this kind of planning we knew the domain, knew each other and our technical knowledge was kind of the same. The size of the team changed over time, but this affected only the lead time because we rarely worked on work items in pairs.
I really enjoyed working like this. It was stressless: no hassle around deadlines and estimations, because everything we did was predicable most of the time. Of course, when we had some performance issues we had some stress, but not because of planning and execution of plans. The pictures above were taken after four weeks of usage but we used this technique for three months until the end of the project. I can only recommend this technique, and if you are interested in the #noEstimates movement, this is a good start. You don’t need a physical board either. You can have a bit wider Done column, or a different kind of Archive board. Here is an example from Leankit:
comments powered by Disqus