A typical Scrum board contains four columns – one for the User Story, a ‘To Do’, ‘In Progress’ and ‘Done’ for tasks. Is there anything else useful to track, asks Bruce Keightley?
This was originally published on the Clarus website.
If there is room, a burn-down chart and impediments section can be added – and if it’s huge, then a technical debt section can be included. The Scrum board shown below made great use of the boardroom window – and the Venetian blinds helped the Scrum Master keep the stories and tasks lined up!
Breaking stories down into tasks in Sprint Planning 2 is not an exact science. You can’t think of every possible task for every story in each sprint. Quite often, it isn’t until we start work on a story that we discover the tasks we hadn’t thought of during planning. I classify these new tasks as ‘found work’ and make them highly visible on the Scrum board by choosing brightly coloured Post-it notes.
The Scrum board below shows the end of Sprint 1 for a team that started Scrum with a group of stories that were ready to be handed over to QA for testing. The pink Post-its represent the re-work of tasks as a result of testing and it is easy to see the amount of this found work. In the sprint retrospective, we can look at the amount and nature of the found work and see what lessons we can learn for the next sprint.
But what about tasks that take longer than we thought?
The Scrum Guide places the focus on the work remaining and is not interested in how much work has been done on any given task or story. The logic is that the team needs to know what effort is required to complete the forecast work by the end of the sprint – which makes complete sense. However, after training and coaching hundreds of people in Scrum, I have found a useful addition. Scrum is about inspect and adapt and, in the early sprints, it can be very useful to understand the work done as this can help identify work that has taken significantly longer or shorter than planned. We can then analyse this work to see if there are any lessons to be learned.
For example, take this fictitious task. I have my name on it and it involves ‘Code xyv for client interface A’. The team originally estimated five hours’ work. At the first stand-up, I update the team on the task saying that I did four hours’ work but there is still four hours to go – ‘4/4’. At the second stand-up, I explain I did a further three hours’ work and there are still two hours to go – ‘3/2’. And finally, I report that the task is done and I spent a further four hours on it – ‘4/0’.
Over the course of three days, 11 hours were worked (just add up the left number of each fraction). This is more than twice as long as anticipated – which is fine – after all the five hours were a forecast, not a commitment.
However, it might be useful to analyse what happened. Was the task simply bigger than we thought? Was it more complex? Could we have foreseen that it might have taken longer? Is there something about this type of task that we can learn from and apply the next time we are working in this area?
The result of the analysis may well be that ‘stuff happens’ and ‘it sucks to be us right now’. But equally, it may point to a more widespread and deeper issue worth understanding.
The same analysis can be applied to stories that take significantly longer than planned. The aim is to learn as much as possible from what happened so that we can apply what we have learned to what comes next.
Taking this approach, over time teams improve their performance via constant learning. Learning from our work becomes standard, leading to improved estimating and a breaking down of the work.
There is a lot of value in the data that comes out of Scrum. Why not look at implementing some simple analysis to better understand your work?
If your team is 100 percent allocated to your project, how many hours of useful work can individuals expect to get through each day? A good starting point is to accept that your organisation will be busy sending you emails, wanting you to fill in your timesheets and bothering you with phone calls – all of this ‘corporate noise’ using up around two hours a day. So, for planning purposes, I use six hours per day as the figure in sprint planning to work out everyone’s availability – if they are 100 percent on the project.
But what about non-sprint work that team members are asked to do? What value is there in capturing this? I would argue that it’s quite a lot.
Now, I’m not in favour of capturing the corporate noise, but if a team member is working on a non-project task for more than 30 minutes, perhaps it should be recorded in some way. The aim is to be able to identify what is taking team members’ time away from sprint work and to what extent. I have found that team members are not aware of how much time they are ‘pulled’ away from the sprint because it happens half-an-hour at a time and when they see the total at the end of the sprint, it quite often surprises them.
So what do you do?
First of all, make a non-sprint lane at the bottom of the Scrum board. The non-sprint work can then be captured quite easily at the daily stand-up using a Post-it note. Each team member notes what the non-sprint tasks were and how long they spent on each. The Post-it notes are then put in the ‘Done’ column of the new lane.
At the end of the sprint, the total hours worked off-sprint and the nature of the work can then be analysed and the team can make some decisions on how to minimise the impact of this extra work.
What I quite often find is that bad behaviour in the organisation is rewarded because team members are naturally helpful and hardworking and don’t like saying no.
So why not try recording non-sprint work and see where your time is really being spent? The answer might surprise you.