How should I break this user story into tasks

Question

I am trying to understand how to create user stories and tasks. I have read articles stating that you should create small user stories and they should be a "vertical slice" of functionality instead of a "horizontal slice".

I have a user story:

As a buyer I want to add items to the shopping cart so that I later can buy the items.

From my understanding tasks should be the things you have to do in order to complete this user story. Am I right if the tasks should also be created as "vertical slices" instead of "horizontal". Instead of creating a task for "create shopping cart model" I would have a task "Update shopping cart service to be able to add products".

But with that task I only have one task, is it to big, should it be broken down in another way? Is it bad that a user story only have one task?

Answer 1

Yes, user story says what you want to achieve, the tasks say how you go about making that happen.

In this case, for example. The tasks could be 'add item to cart UI button', 'check stock levels', 'get user account', 'update temporary cart', 'update user account last-bought list' etc.

Its possible some of those shoudl be part of a different user story, but I wouldn't worry too much about crossing every t and dotting every little i, the important thing to focus on with agile is getting it done, not working the bureaucracy.

Answer 2

When we talk about a vertical slice of functionality, we're talking about the user story only.

Tasks are broken down in to whatever the development team feels appropriate, to complete the story.

Answer 3

It Depends :)

I don't know the context of this story, but on face value it sounds to me like the only task here is add-item-to-cart. In a typical browsing/shopping application, this would be an AddToCart button, with appropriate button-click logic, where the user/cart identity already exist.

If user identity and a cart cannot be assumed, I suggest that you don't break them out as tasks under this story, but instead separate them out as new stories.

If you just reveal the presence and behavior of the cart (and/or user identity, if necessary) via a task breakdown, you will have missed an opportunity for much more informative, valuable conversations with the users (what does the cart look like? where should it appear? can you remove items from the cart? etc.).

Answer 4

I think you're thinking too hard. Let's say I come to you and say "please make me a shopping cart for a website". What are you going to to? Ignore all theory and buzzwords and dogma, what are you going to do when you sit down at a keyboard?

Tasks are just a list of the things you need to do.

1. Write tests
2. get graphic for the "add to cart" button
3. ...

Answer 5

I don't tend to think of tasks as "slices". They are the things you need to do in order to implement a given user story, so are often things like make a schema change, add a new class, add a new method, add a page, style the page etc. You wouldn't typically have one task to implement the whole feature. If you're going to think of them as either vertical or horizontal slices through a user story, they are definitely more horizontal.

Taking a vertical slice of a user story is typically used for splitting one large user story into several smaller ones if your team conclude that it is too big, e.g. if it gets an estimate of an infinite number of story points in planning poker.

If this were the case for your shopping cart example, with a little bit of artistic license, I might break it down into the following different user stories:

• As a buyer I want an add to basket button on every product page so that I can click it to add the product to my basket once that functionality is implemented.
• As a buyer I want to enter the quantity I want to add to my basket so that I can add more that the default of one.
• As a buyer I want a quantity of items to be added to my basket when I click the button so that I can later buy the items.
• As a buyer I want a confirmation screen telling me what I've just added to my basket so that I can correct any errors I might have made.

These are vertical slices through all layers of the system, each implementing data storage, business logic, user interface and everything else needed for a working, albeit not feature complete, system.

This is however the exception, only to be used to deal with user stories which are uncomfortably large. Typically a user story will be of a manageable size and can be broken down into tasks to describe the steps you will take to implement it.

Answer 6

In my opinion it depends on the weight of the user story. If the user story is about only adding the item to cart, first task should be getting the design for this approach.

After that you have to break up the tasks according to the design (loggedin scenario, if not loggedin, so on).

Answer 7

Assuming you're a product owner or business analyst, don't. Tasks are generally not created by PO's or BAs because they focus on technical details, not requirements.

If you're in a dev or QA role think about tasks as tools for the development team to understand the work steps needed to complete the user story. Formal tasking can be a good way of getting development teams to start work on a story and get past the initial story point estimate.

Depending on your team, tasks may be non-existent to extremely granular in your Agile tracking tool. Its the thought process that counts. Generally you'll see and think about several categories of tasks depending on how detailed your team likes to get.

Research tasks Implementation tasks Code quality tasks Testing tasks

If your task isn't helping you fulfill acceptance criteria or the team's definition of done, consider if it should really be part of the story.