Tasking in Scrum: Why We Value Story-Breakdown over Work-Breakdown

A great deal of potentially dangerous confusion and guidance exists around the subject of "Tasking" in Scrum. You'll encounter wildly different guidance on the subject. SAFe, for example, says that they recommend against them (largely for the reasons outlined in this article), but can be useful for teams getting started. Others suggest it's just a good way to roll always.

So which is it? Let's dig in. 

Before we start, we should make sure we understand that the term as the word "task", and the derived verb "tasking", can mean different things to different people. If you read "User Story Mapping, by Jeff Patton", for example, you'll see "Tasks" in a Story Map as the things people want to do while telling the Story of what outcome they want to achieve, not the "things to do (i.e. work-breakdown structure) to accomplish a goal". It is the latter definition that I am referring to in this blog post. 

Tasking as a management imperative, to track the work being done, can work counter to our other Agile inspired practices.

For example, if we attempt to use tasks in this fashion, we potentially invite: 

• Parkinson's law. Work will expand to fill the estimate.
• Time spent in bookkeeping that isn't adding value
• Discourages the advancement of cross-functional teams. We'll see tasks decomposed by the "experts" in that subject on the team
• We become template zombies over time. "Define it, Build it, Test-it, Nom, Nom, Nom"
• Difficulty knowing where actual story progress is during the sprint (90% of task completion but the last 10% takes triple the whole-time).
• "Busy-ness" becomes the primary measure of progress
• Management looks to optimize utilization of "resources" which will, predictably, cause utter collapse in flow of delivery
• Utterly duplicative. If the teams know the tasks to do than just do them.
• Output is not the same thing Outcome.
• It is rife with abuse
• Delaying one task delays another task - just like it always has
• The focus is on the task and the plan - this crushes any possibility of innovation along the way 
• It is "following a plan" over "responding to change"
• Tons of extra work by the developers that adds no value
• As an excuse to not decompose stories into small vertical slices
• Demoralizing order-taker mindlessness
• The list goes on...

Now, "tasks" aren't bad, per se.

I routinely use them.

All the time.

At work, at home...just about everywhere.

But I use them in an agile way. I scribble the list on paper and delete it when a better idea comes along. I don't agonize over how long the task is going to take because the task will take what the task will take. What's funny is I regularly achieve the "value" from the thing while many unfinished, or different, tasks remain on the list. I use them to guide me but they are never "the thing of value". 

Here are my heuristics for the use if tasking as work-breakdown structure:

• Tasking can be useful on many levels when used as an 'emerging dynamic checklist'
• Therefore, the approach must "support changing tasks, even late changing tasks" as new information is obtained to allow for a better plan
• Do not record tasks in an ALM. It's pure waste
• Do not use tasks to measure progress (working software is the primary measure of progress)
• If you must put tasks in the ALM do not put time on them
• Teach leadership to trust the teams
• Focus on User Story understanding and decomposition instead
• make your stories smaller and constantly work on the abstractions
• use User Story Mapping and BDD to create a shared understanding
• pair on all stories
• communicate in person as a team, not through the ALM task "work breakdown structure
• Do burn-up story points
• Do let the teams decide for themselves if and how tasking is useful
• Do use the time you would have spent tasking to understand the customer needs better and to build quality in, instead.

ReplyForward