Explaining the difference between Product Backlog Item and a Task

Question

I've run into this challenge a couple of times and I'm hoping someone can provide some references, training or advice on how to explain the difference between a Product Backlog Item and a Task in TFS.

I understand and have explained that a Product Backlog Item is the "What" and the Task is the "How". I have also explained that the PBI is the requirement and the Task is how the requirement is met.

I'm repeatedly met with blank stares and head scratching when I explain this. It seems that the Software Engineers I explain this to can not make the distinction. It is all the same to them.

I believe my other challenge is that I am not able to effectively illustrate why it is important to make the distinction.

Answer 1

The "Product backlog Item" is indeed the What, the functionality that needs to be built. The Task describes the steps that need to be taken to get there.

Many teams are not used to decompose into tasks, they just build what the spec says. For these people it's hard to see them as two separate things.

Maybe a simple anecdote would help:

See the Product Backlog Items as the items on their shopping list for their vacation. Maybe a "tent", a "fishing rod", a "prepare car for travel".

The Tasks for the "tent" item would be "Describe tent requirements", "Compare tents online", "Get advice from friends with outdoor experience", "Go to outdoor shop", "Buy tent", "setup tent in backyard to verify completeness", "pack tent for travel"

The Tasks for Fishing Rod will be very similar, but the tasks for "prepare car for travel" are probably very different: "Check requirements for states/countries on desired route", "buy safety vest", "replace expired contents from first aid kit", "inspect spare tire", "schedule appointment with garage to have engine checked", "go to garage to have engine checked", "go to state agency to buy highway pass", "check car insurance"

This clearly separates the question of what the product owner wants from what they need to do. Unless of course the product owner already decomposed into actionable items on the Product Backlog, in which case you also need to talk to them.

As I said, for many developers they think they already have enough information and know what to do, they don't want to decompose the What into How steps, they'll get there when they get there. When you start talking to them about tracking the sprint progress, improving estimations, tracking work that was forgotten during sprint planning and other items that have to do with professional improvements, ask them how they and their team will know where they can improve and how they know they're really done. When they can come up with a system that works without creating tasks and it works, then that's fine, but chances are very low that they actually can.

Before trying to work with TFS and the agile tools, your team will need to understand how this all works. The best way is to have them work with a paper board, which is visible on the work floor to all. Later, when the process is understood better, moving to the tools will help. Without the understanding, the tools won't be of much use and will meet a lot of resistance.

Answer 2

I think Jesse has provided a great answer. I'm simply going to try and make it, well, simpler (if possible) :) The Product Backlog Item (or User Story, if you prefer) is usually written like this:

As a New Customer I want to register my details So that I get informed of new product releases

In a developers head this may translate in to:

1. Create a registration form
2. Write registration data to the database
3. Send email to the new customer to confirm their registration

These three items are the tasks.

Hope that helps.

-- Make it as simple as possible but not simpler (Einstein)

Answer 3

Here's how we roll:

The PBI:

• is the requirement aka "the what"
• is what you talk about with a customer.
• It's what shows up on the Daily Project Update (DPU) for the sprint..... again because the DPU is customer facing.
• It's what the customer will talk about and refer in terms of estimates and budget.
• Might comprise one or more tasks.
• Is business oriented and described in business oriented / domain style language that the customer understands.
• Is what gets tested and accepted in User Acceptance Testing (UAT)

The Task:

• Is a piece of work required to materialize the PBI (requirement)
• Not something you talk about with a customer
• Doesn't show up on the DPU because you don't talk about them with customers
• Is estimated but has it's estimates rolled up into the PBI
• Is a child to one and only one requirement.
• Can be described (and often is) using technical jargon
• Tested internally and signed off by test
• Not accepted or tested in isolation by the customer (they don't know they exist)

Answer 4

I also heard this split that makes it easier to understand:

• Epics - month worth of work
• Features - weeks worth of work
• PBIs - days worth of work
• Tasks - hours worth of work

Answer 5

I tend to offer this when asked:-

A PBI, or Story is something more than one person can get around.

A Tasks is something only one person can pickup.