«

»

Mar 27

Task driven Scrum

tasksAs a scrummaster there are a lot of things where you can focus on. Making sure userstories are written correct and that the team understands them. Making sure that the standup is done correctly. Getting a lot of info from the retrospective. And so on. But with almost every team I have coached I stumbled upon a very simple thing that has a lot of impact and one that is also very visible. It can be the first thing for a Scrummaster to act upon but also in most cases the scrummaster who is implementing scrum makes this first mistake. The mistake of the task driven Scrum.

In scrum we have the idea that the product owner provides the team with clear written user stories. These are stories with a function description of what is needed. The team estimates these userstories with scrumpoker and then determines what is needed to be done in order to get the stories done. The team writes tasks. Now a task is something that the team needs to do. Like write code, test code, cleanup something etc. Tasks are the jobs that the team does to get the work done. Some teams also estimate these tasks in hours. The largest task can be not longer then a day work.

It is to my opinion that the estimating of task is only extra work and does not add anything to the scrum. Ok, a project manager is happy with it but apart from that, no good ever comes from it. Especially when the team starts to track the tasks. I’m sure you have seen these sprint boards. Userstories on the left in the “To do” section and the task are being moved across the board. I have seen boards where every task also has a picture from the teammember working on it. Now this might work with a Kanban but not with scrum. When you only track tasks you get the task driven scrum. Individuality is endorsed.

When only the tasks are moved across the board a few things happen.

  • First of all every teammember picks his or here own work and working together on a single user story is in most of the cases not happening.
  • Next, because everybody works on various tasks, the change that any userstory is delivered at the end of the scrum is minimal.
  • And finally when your burndown is based upon the storypoints it stays flatline so you are not able to help the team or track progress.

In the beginning it seems like a good idea. Everybody is working on the software and it looks like the board is working and moving. But it does not work. As a scrummaster you should end this behavior as soon as possible. Bring the team back to one or two userstories to be worked upon. Teammembers might argue that they sometime cannot work on the same story. It is then a good idea to let them pair, test or write documentation. They have to work together to get the stories done and not just the tasks. Allowing everybody working on individual task is not effective and does not help the team and therefore the end product.

Permanent link to this article: http://agilethings.nl/task-driven-scrum/