Is formal tasking required on a Scrum Team

Question

I understand formal Agile-Scrum tasking as the practice of documenting tasks and estimating task hours for each story or product backlog item a team commits to in an iteration. A task defines part of the "how" the story will get done. Usually I see teams task out their stories during or soon after an iteration planning session.

Are you still following Scrum if a team doesn't formally task out and track task progression in an iteration?

I've worked with several, what I consider, mature teams that don't task at all and work solely at the story & story point estimation level in managing their commitments.

What are the benefits of not formally tasking?

What are the risks?

Answer 1

Some would argue you are following Scrum even more if you don't use Tasks. What's happened is over time we've had a merging of terms and through that a duplication.

Coincidentally enough, Mike Cohn wrote on this just yesterday (June 23, 2015).

The Scrum guide talks about "tasks". "User Stories" came from Extreme Programming. As the first two agile frameworks they have begun to merge and share terms over time. A task and a user story should be the same thing.

What I think has happened, is a fairly classic split between those generating the requirements and those building the requirements. Product Owners would define the user story. These stories were often poorly translated product requirements. As a result they lacked detail and were often high level. During planning, the developers would then break down stories into tasks (or developer tasks) to break out all the work that needed to be done.

What should be happening though, is better user story creation. If a developer needs to break a story down into tasks, then the story probably hasn't been decomposed enough. Product Owner and development need to work together on backlog grooming. User stories should be fully "ready" before development commits to them in a sprint (we are in fact starting to see the term "definition of ready" to note this).

Task Hours is again another invention of organizations moving from traditional to agile. It can be useful early in an agile transformation, as it helps to create that bridge in metrics and reporting. However it can be a crutch and lead to estimates falling back into traditional models which didn't work so well. This has lead to relativistic estimating (comparing one story to another, instead of estimating a single story). There is a $0.99 book on Amazon that discusses this method. I give a brief outline of the exercise on my blog in "How much for that gorilla in the window".`

Conclusion: Decompose your user stories down to something that can be done in 2 days (for a two week sprint). Assign clear acceptance criteria so developers know how to get to done (needed for "ready"). Use Relativistic Estimating.

Ditch the tasks.

Answer 2

A great deal of dangerous confusion exists around this subject.

As one author noted even the term 'task' means different things to different people, so make sure you're talking about the right thing in your context.

If you read "User Story Mapping", Patton, you'll see a definition of Tasks as the things people want to do in a Story, not about the "things to do work-breakdown structure". It is the latter definition that I am referring to in this answer.

Tasking as a management imperative, to track the work being done, is extremely dangerous.

Perhaps the worst practice of all the other agile anti-patterns combined.

• 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
• 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 valuea
• 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
• 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

Some better ways:

• 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

Answer 3

I only partly agree with the above. I do think that tasking is something that can sometimes be dropped as a Scrum team matures. Tasking is best used early on when it provides a means to accelerate a team's understanding of the processes, dependencies and typical workloads associated with delivering a story.

Why do it?
Because it gives you metrics (e.g. burn-down) that flag up problems within a sprint, helps the team learn and helps spot and remove impediments. It helps you understand at a detailed level the mechanisms of delivering a story, leading to more velocity more quickly.

Why not do it?
Because it costs a lot of time. It may seem like a small job to task out and revise hours remaining - but it can take man-days out of a sprint.

So for me, it's worth doing in a new team or a new project - but you have to spot the point where you're no longer getting value for the time invested. At that point, drop back to stories only and see how it goes.

I hope that helps.

So where do I disagree with the above?

Well, tasks and stories are NOTHING alike.

A story is the "What and Why", a task is just the "How". The two must never overlap, as you have to maintain the independence of requirement and solution. The product owner has to own the story. The team have to own the tasks.

Any overlap or confusion between the two suggests, to me, something being very wrong in the dynamics of the process - usually too much influence on the 'what and why' from the techs, and/or too much influence on the 'how' from the product owner. And that's never good!