Should we create sub-tasks for each story by default representing all the different types of work the story will require

Question

One of my colleagues proposed an idea to split stories by default each time we write stories for the project into sub-tasks to represent different types of work a story has.
We are using Scrum and Jira at work.

The pros of that approach as I see them are:

• transparency
• probably better estimations ("probably" because this will be more difficult to align a sum of multiple story points estimations from the sub-task with the Fibonacci sequence)

The cons, however, are pretty substantial in my opinion:

• more work to organize the workflow
• huge rise of the number of PBIs (product backlog items) which will screw up the statistics of sprints
• the team still has problems with passing the items around the Kanban board and reassigning correct people at different stages of development. In the scenario proposed we will have to interconnect sub-tasks and then manually go through the PBIs to make sure certain stages of development are complete
• there has to be a reason for each PBI to exist in the backlog - if I create PBIs just because I split all the stories by default, the whole process becomes less meaningful and I just let it slide
• we have already got 1500+ PBIs so it would make it difficult to switch tracks mid-project even for only open stories

In the end, I think that I should keep it simple but I would love to get your ideas so I could make sure that I am making a well-informed decision and not missing anything.

Answer 1

The proposal for adding sub-tasks to every user-story up front for each type of work involved in completing the user-story assumes a different way of working with sub-tasks than you are currently doing.

Presumably, the person who made the proposal had in mind that the user-story would remain the PBI that gets estimated and planned. The sub-tasks would then on the one hand be a reminder to the team while estimating the story what work is involved in completing the user story and on the other hand would give an easy division of work when multiple people start working on the story.

This means that those sub-tasks would not get estimated individually (and definitely not in story points according to a Fibonacci sequence) and would also not be planned individually. That all happens on the user-story level.

If you decide to go with this proposal, you will have to think about how to deal with user-stories that are too big for one iteration and which you currently split into sub-tasks, because using both practices at the same time would only cause confusion. An alternative here could be to split into two user-stories and either promote the too large story to an Epic or to put both new stories under the same (existing) Epic.

Answer 2

This is a fairly common approach taken by many teams. Often times the teams find it helpful to have those sub-tasks to organize their work. At the same time, it is not strictly necessary. Many teams do fine without them. The one trap to it is that you need to make sure that focus doesn't move so much to the sub-tasks that attention leaves the backlog items. Those backlog items are still what deliver value.

One other point I'd share is how those sub-tasks usually get created. If you look at the structure of Sprint Planning in the scrum guide, there are three parts: The why, the what, and the how. Part one sets the direction for the sprint, usually resulting in a preliminary Sprint Goal. Part two identifies which backlog items to work on that will lead to the outcome proposed in part one. Part three is space for the team to create a first pass at the plan for how to deliver on those items. This is normally where those sub-tasks would get created. To that point, the right sub-tasks to create are the ones that help the team organize their work to deliver the backlog items selected and fulfill the sprint goal. This leads to valuable sub-tasks that will align with the work needs to be done.

Answer 3

In my opinion, your colleague's suggestion is an excellent one. "'Stories' refer to what the user will eventually see – not the prestidigitation that will be required to finally let him see it!

If it so happens that, in your "shop," the "stories" that are coming in can be usefully subdivided into classes – especially classes that suggest any sort of common implementation or re-usable approach – then I think that you should immediately seize upon the idea and run with it.

"Stories," after all, are purposely an abstraction. But, in your boots-on-the-ground situation, this is something concrete.