Moving beyond tasks

One of the most common agile anti-patterns I witness is a compulsion towards breaking user stories into tasks.

Tasks take focus away from stories

The problem with tasks is that they take the focus away from user stories. Teams that focus on completing tasks risk losing sight of the real value which lies in the stories. They are often unable to see the wood for the trees.

How often have you seen sprints that are?

•             On day 9 of 10, but <30% of story points are complete

•             On day 5 of 10, but <10% of story points are complete

•             On day 9 of 10, with 90% of tasks complete, but still <30% of story points complete

I firmly believe this is a by-product of too much focus on tasks and not enough focus on stories.

Tasks themselves add little or no value on their own. I often see tasks such as “Manual QA”, “Code Review”, “Write test cases”, “Database work”, “Front end work”, “Back end work”. People often argue to me that the task breakdown ensures they don’t forget to do certain parts of a story. If we need a task to remember to do code reviews and testing then we are in big trouble J.  Also a simple check-list will suffice, that doesn't have any rally/ jira overhead.

Tasks are unlikely to help you to limit your work in progress

Let’s say a sprint starts with 10 user stories. Each story breaks down into 5 tasks giving us 50 tasks to get through.  Let’s suppose a breakdown of 20 front end tasks, 10 middle tier, 10 back end & 10 test and a team consisting of 1 FE, 1 Java, 1 DB and 1 QA.

Day 1 of sprint everyone is eager and wants to start a fresh, new piece of work. Everyone will naturally choose a task that fits their specialism. If we are lucky there will be some alignment so that we at least have multiple people working on the same user story. As people start finishing their tasks, they will, again, naturally choose the next task from their specialist area. They bring a new story into play, thus increasing the amount of work in progress. Nobody ever picks from outside their specialism which ultimately leads to a large portion of stories in play at any given time. This gives us the situation where lots of stories are starting but not many are finishing. Not to mention a massive tendency towards specialism where each person stays rigidly within their own skill set.

Why do we want to limit WIP?

CFD charts that look like this highlight a large amount of WIP. 

Halfway through the sprint there is very little work complete. This is a big risk that the sprint is going to fail. Or at the very least it doesn’t inspire confidence that the investment in the sprint is going to deliver.

CFD charts like this one provide more confidence that work is being delivered incrementally & early and the risk of failure is reduced. Its no coincidence that this team has limited work in progress throughout the sprint (the yellow section)

The more WIP, the more EXTRA UNNECESSARY work we generate for ourselves. There’s additional overhead of merging, managing the separate stories and tasks, discussions between developers and QAs about ALL the stories in play, discussions about integration of all the stories in play etc. It’s much more difficult to integrate with moving targets. Every new story you bring into play results in a delay in getting currently 'in progress' user stories into DONE!!

Finally, and quite simply... Managing tasks is waste! They introduce an unnecessary management overhead. Each task needs to be managed in rally/jira. Undoubtedly, precise estimates will be required (in hours) for how long each task will take. Time spent on a task versus the estimate will no doubt be tracked. All of this is time spent NOT adding value for the customer.

Limited WIP helps you delivery incrementally

Incremental and early delivery of your sprint user stories gives the following benefits:

• Reduced cycle time (due to less unnecessary work mentioned above)
• Reduced risk (earlier delivery)
• Fast feedback (early integration/ early visibility of deliverables)

These are some of the main gains we should get with an agile development methodology. Otherwise we are doing big batches of work that inherently hold risk, and are delaying visibility of deliverables.