I recently had a day at home with my kids and we decided (well I decided) that we’d try a new game. I explained the rules:
“Today we are going to get lots of jobs done, but before we do anything we are going to divide up the whiteboard into columns; to do, doing and done. Next we are going to write all the jobs we’d like to do on sticky notes and place them into our to do column. Finally we’ll pick a job to work on and move it into doing.”
For those of you who haven’t come across this technique before it uses a kanban board. It is often used in agile or lean development as a way of visualising work, limiting work in progress and providing a focus on getting items to done. Here’s our board at the start of the day:
So what did we learn? Well the first thing I learnt was that kids love using sticky notes, they loved writing on them and moving them across the board. I’m pretty sure that adults do too!
When we started, our target was to get all jobs into done before the end of the day. We didn’t spend any time estimating the tasks as that wasn’t important to us, the time was better spent actually doing the tasks. As you might expect, we didn’t finish all the tasks, however the sense of achievement from the large number of tasks we did achieve was great.
We also uncovered a lot of the common issues I also see at work. Some of the tasks in our backlog (to do column) were too vague and were actually several tasks in one. For example, one task was to empty the wash basket. That was actually several steps; put first set of clothes in washing machine and wait for it to finish, hang out wet washing when finished, collect dry washing from outside and then put away. With a sprint of just a single day, and several washing loads to do, having a single task of many hours was not granular enough.
As Dad in charge (product owner) I was able to groom the backlog, breaking down these epics (empty wash basket). I was also able to look for a natural order to the tasks, e.g. once the dishwasher was running we had an hour for other tasks whilst it completed its cycle so it made sense to prioritise that task above some others.
The final item we learnt was in defining our acceptance criteria, i.e. what does done look like? One task was to tidy a bedroom. This was too vague and subjective, who decides a bedroom is tidy? Instead we employed a technique called time boxing. The task became “spend 15 minutes tidying bedroom” with done now clearly defined as 15 minutes worth of tidying. After 15 minutes that task moves to done, and as product owner I could evaluate and decide if I wanted more effort on tidying that bedroom and create a new task in the backlog.
It’s perhaps worth noting that a more traditional waterfall approach to this problem of whether a bedroom is tidy or not would have been to produce a more detailed definition of requirements up front. I could have listed all the items that needed tidying away, that the bed needed making, bins emptying etc. However, the common problem is that not only does this definition take time, it can also miss vital parts. If I forgot to say that I didn’t want sweet wrappers on the floor then it would be possible to say the bedroom was tidy (according to the requirements) even though as product owner I could see the wrappers on the floor and so know that the room wasn’t tidy! Another common problem with this approach is when the requirements are actually unclear, e.g. I know the bedroom is untidy, but I don’t know how to make it tidy, or how tidy I actually need it. A time box approach allows the team to spend an agreed amount of effort and the results to be evaluated. No extra effort is wasted making the room tidier than needed, and some progress may help me as product owner to realise what further parts of tidying the room are important, e.g. Now I can see the carpet as the toys have been tidied away, I now want to focus on making the bed and taking dirty pots downstairs, but that is probably all I need.
Here’s our board at the end of the day: