Subtasks handling is sprints

[Xavier Chevalier]

Hello there,

My team and I noticed that subtasks of stories are not visible in backlog, and that you cannot put only one subtask of the story in the planned sprint but only the full story.

Moreover, when a subtask is done and the sprint is closed, it still comes back in the next sprint in the "done" column, which is not very conveniant since it was finished during the previous sprint.

So we think that it could be good to select subtasks to plan in sprint and when they're done, not having them come back in the next sprint. 

That's why I'm creating this discussion, to see if we're not the only ones and if it could be implemented.

[Nic Brough -Adaptavist-]

This is working as intended, as far as Atlassian are concerned.

A very cut-down version of a description of scrum is that you have a list of stories that you deliver to a "product owner".  A sprint is a time-box, in which you tell your PO that you ar going to complete a collection of stories.  These appear in the backlog and are the primary items.  The backlog is ordered by the whole team, but with the PO driving what the most important items are.

Your developers, if they want, can create subtasks to break up stories, assign bits of them to different people, have different workflows, whatever. 

But sub tasks are irrelevant to the backlog.  You commit to stories, not sub-tasks.  They only matter within the context of the story they belong to (it's nonsense to rank them in the backlog outside the issue) and your PO does not care about them - a story is either done, or it is not.  If less than 100% of the subtasks are done, then the story is not done, 1% or 99..% - all not done

[Xavier Chevalier]

Hey, thanks for your reply !

I understand what you mean and I guess it's the right way for the agile method to work but do you know a way to do what I said I'd like to do ? Because we are working on a prototype and we'd like to cut the tasks as much as possible so it's better sorted and easier to follow what's done and left to be done.

[Nic Brough -Adaptavist-]

You need to take those sub-tasks you want to use in sprints and promote them to stories - they are not sub-tasks if you want to use them as sprint items.

[Xavier Chevalier]

Okay, thanks for the advice !

[Mark_Booth]

When the same question keeps coming up month after month, year after year, you have to wonder if the design is wrong.

In user interface design, you should always strive for "Don't make me think".

If the obvious way to divide up a big story is to add sub-tasks, then you should be able to add those sub-tasks to a sprint.

Forcing people to re-work a task+sub-tasks into an Epic+tasks just adds extra friction.

I've lost count of the number of times I've had this exact same issue over the past 8 years, I always do the obvious thing first, find it won't work, and then have to fiddle with it until I've jumped through the hoops - usually by doing a search and finding questions and answers like this one.

I'd rather it were just possible to do the obvious thing straight off the bat, and given the dozens of questions on this, I don't think I'm the only one.

[Nic Brough -Adaptavist-]

I didn't really "get" it either, until I came to understand Scrum properly.

A sub-task absolutely should behave as it does in Jira.  It is part of a Story (issue) and it's really nonsense for it to be treated as anything other than that part of a story.  And if a story is in a sprint, it's nonsense to have parts of itself in other sprints. 

Where I think Jira falls down (and I have a nasty habit of "fixing") is that it fails to inherit properly and doesn't imply that a sub-task is part of its parent strongly enough.  I often create a "sprint indicator" type field for sub-task that draws from the sprint of the parent, so that you can at least see and report on it (and, while we're there, "Epic name from parent" as well)

You're definitely not the only one, the problem is that Scrum is not as intuitive as we'd like, and Atlassian have implemented sub-tasks for Scrum, not for non-Scrum.

[James Bullock]

What @Nic Brough -Adaptavist-  said.

Or to put it another way, only stories exist independently. Sub-tasks incidentally may exist, belonging to a story. "Epics" collect stories sometimes. A Sprint (or "Iteration" in XP) allocates work to get some stories "done."

Kanban / Lean abstracts this a bit, so the thing that's workflow-managed is a "single independent piece" of no particular kind, thus: "Single-piece flow."

This is where I do my "do the domain entity model" dance, again. All the method prescriptions presume a particular domain entity model for the work you are doing, without calling it out directly, without specifying everything about the model or the entities.

With a proper domain entity model in hand, it would be unavoidably obvious that in Scrum-world things that span Sprints aren't sub-tasks, or even stories. Also that the hack is to split the Story, so each part fits in one Sprint. Then you track the bigger assemblage as a collection of Stories -- an Epic, in their terminology.

[Nic Brough -Adaptavist-]

I think Jira falls down on its very simple approach of "ignore sub-task estimates".  It is absolutely correct for sprint, burn-down, velocity and so-on. 

But I do have a good understanding that estimates on sub-tasks are useful, as they can feed into "how is the sprint going" with a lot more granularity than "story is done".  It is useful for a team to see "whilst our PO sees 3 of 5 stories are done, and the other two are not, we actually know and care that the 4th story is 5% done and the 5th 86% there".

But this does lead us into interminable discussions on the "right" way to implement such schemes.  My experience suggests

• Estimate stories, then as sub-tasks are created, estimate them, and effectively subtract that from the parent estimate
• But, roll it back up, so the parent estimate does not appear to change in scrum terms (unless the sub-task estimates come to exceed the parent total - that's a clear indication of needing change)
• Have two sets of reporting functions.  "proper" reports, as they are now, but add some so that a team can track their sub-task progress while keeping an eye on the upper level data.

There are plenty of other ways to help teams track and report, of course.

[James Bullock]

That's a nice progress-wrangling hack. I'll trade you one of mine: for progress tracking accept done fractions of 0, half, and complete.

Both of those progress-wrangling hacks are about getting the tool out of the way, to do tracking in a way that helps better see what's actually going on. They work in different situations, roughly:

• Production is working; the tool is losing granulatiry on what you actually know about what's going on. So, let relevant granularity filter through.
• Production isn't working; the tool is masking the non-performance in clouds of detail chaff. So, bottom line to unequivocal stati.

Both hacks adjust toward  more accurate information. The trick is knowing when to use which, or something else. (Insert my rant about "Use Cases Without Forces are Bad, Wrong, and Worse Than Useless." We're talking about a "Wrangling dev production." use case, with unknowns and politics among the forces.)