1

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.

Improve this question
3
  • Are you currently using sub-tasks at all? If so, how are trhey currently being used?
    – Bart van Ingen Schenau
    Commented Jan 25, 2021 at 15:18
  • @BartvanIngenSchenau yes, we are using sub-tasks but only if a story is too big to be delivered in a time frame of one sprint. Else, we do not divide stories into smaller pieces.
    – chullspen
    Commented Jan 25, 2021 at 15:40
  • 1
    I don't think that transparency is improved.. Usually we don't finish LayerA, then start working on LayerB, then LayerC. Often we write them all simultaneously. So all of these sub-tasks will be started and finished at the same time - and thus they represent 1 atomic task.
    – Stanislav Bashkyrtsev
    Commented Jan 25, 2021 at 15:43

3 Answers 3

Reset to default
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.

Improve this answer
1

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.

Improve this answer
2
  • Thank you for you comment. We moved from creating PBIs exactly at the Sprint Planning because if we do that, the time needed will skyrocket and the PBIs on the bottom of the list will get overlooked or not properly estimated due to the fatigue of the team members. Instead, we run refinement calls along the sprint to prepare the future Sprint Backlog beforehand. So at the Sprint Planning regarding defining the scope of the sprint we only choose what to work on guided by urgency and ROI and discuss dependencies and blockers apart from everything (goal, availability, situational overview, etc.).
    – chullspen
    Commented Jan 25, 2021 at 16:42
  • Again this is good advice I think to just focus on what helps to get the job done. If it's just a ritual or instruction without a purpose behind it, it should be rethought. Here I come to a conclusion that creating mindlessly creating sub-tasks by default is a bad idea and I should stick to what I have.
    – chullspen
    Commented Jan 25, 2021 at 16:46
1

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.

Improve this answer
1
  • Thanks for your comment Mike. Right now we do divide stories into sub-tasks if a story too big and it needs to be represented in a couple lower-level tickets. The question is not about if we should split the stories but if we should split them by default meaning just following a dummy procedure creating a fixed set of stories each time a new story arrives. According to the Scrum methodology, the amount of work which has to be done to an item is everything it takes the Development Team to deliver a potentially shipable increment. That's all that matters after all. Let me know what you think.
    – chullspen
    Commented Jan 28, 2021 at 10:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.