nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Comments

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 !

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.)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

atlassian-marketplace

sub-task