How to deal with tasks detalization in sprint planning?

Question

I have a newbie question. Let's suppose that for a sprint backlog we choose one user story from product backlog: "As a photography junky I want to be able to make a collection of favorite photos".

And then we want to add some more in-detail tasks, for instance "making a mockup" for UX-designers, "making changes to model" for backend developers and doing front-end implementation of design ideas.

So what is the best practice for that? Do we add these sub-tasks to sprint backlog, or we create separate "detailed to-do" backlog? Do we add story points to each sub-task?

With stories points it's an especially interesting problem, because if we add sub-tasks to sprint backlog we are counting tasks twice: first for user-story in general and second for it's parts in form of subtasks.

Answer 1

To capture the technical work that is needed to complete a story, tasks are created that are underneath or a part of the story.
If your tooling doesn't support creating sub-tasks for a story, you can just write those tasks as a bullet list in the description of the story.

In any case, these technical tasks are not backlog-items and thus they are not added to either the product or the sprint backlog. When a story is added to a sprint, the tasks of that story come automatically with it.

With regard to estimation, some teams do an estimation in hours of the tasks of the stories that were added to the sprint during the planning to check that no discipline within the team is overloaded with work. This kind of estimation is completely optional and is independent of the story-point estimations of the stories themselves.

Answer 2

The Scrum Guide

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.

User Stories is one possible technique, not a requirement, for expressing Product Backlog Items (PBI). If using story points then they are generally not attached to anything below the PBI. The selected PBIs are forecast (not promised or committed) by the Development Team and the plan needs only be as granular as needed by the Development Team.

Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting. (Sprint Planning)

The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint.

The Sprint Backlog ... belongs solely to the Development Team.

The answer to how the work is broken down is something for the Development Team to determine: self-organization. Creating tasks is one possible technique, not a requirement, for decomposing the work. Not all of the selected PBIs should be decomposed at Sprint Planning, just the first few days of work: responding to change over following a plan (Manifesto for Agile Software Development).

Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule.

Thinking and executing in terms of front-end developer, back-end developer, tester, technical writer, etc. is an indicator of an opportunity for improvement. (Paint Drip People)

Answer 3

User stories must meet INVEST criteria

You can use the INVEST criteria to decide what constitutes a user story.

• Independent: The story should be self-contained. It should not be dependent on another story.
• Negotiable: Stories should leave space for discussion with the Product Owner.
• Valuable: A story must deliver value to the end-users.
• Estimable: You must be able to estimate the size.
• Small: Stories should be small enough that a few of them can fit in a sprint.
• Testable: The story (and its acceptance criteria) must provide the necessary information to make test development possible.

The examples you gave, "making a mockup" and "making changes to model" do not deliver value to the end-user. So, they are not stories.

If you have difficulty how to split a story, you can use Mike Cohn's SPIDR techniques.

• Spikes: Build a prototype.
• Paths: If there are several alternative paths in a user story, create separate user stories from these paths.
• Interface: in this context can for example be desktop, mobile...
• Data: Another technique for splitting user stories can be used when the initial stories refer only to a sub-range of the full data.
• Rules: Business rules or technological standards can be another splitting factor.

Answer 4

The extra detail (and the tasks associated with it) should be elucidated before Sprint Planning, during regular backlog grooming sessions.

If you wait until Sprint Planning or later to define what you will actually do to deliver a story you will be on the back foot already - what if you realise after you have started the Sprint that it is too much work to complete, or that there is a significant blocker to progress?

Your team should only work from one backlog otherwise prioritisation becomes an issue.

You could capture story points at either the broader story level or the smaller "sub-task" level. I would avoid adding story points at the sub-task level if they have already been allocated to a parent task, simply because of the risk of double-counting. If your parent story is large, the team (and the business as a whole) will not appear to be making progress until the very end - smaller deliverables make it easier to show progress.

You will also find that the software you use to manage stories will influence how you structure them as there are certain approaches that will suit the software better.