Scrum Board: What are the pro and cons of: Userstory + Subtasks vs. Userstories + assigned Tasks

[Daniel Oberacher]

Hello everyone,

I am currently wondering what is more beneficial in kind of setup:

1. Create one Epic - Assign x userstories, define tasks per userstory as subtasks.

2. Create one Epic - Assign x usterstorries, assign Tasks (not sub-tasks) to the userstories.

My goal would be to be able to organize working simultaniously on various userstories - but not having to complete the whole story in one sprint.

It would be perfect in our case to use Stories to group tasks and discuss and track progress in matter of what to present to the customer / Product owner, but depending on what teammates are currently available in the sprint (multi-project organisation still) able to put each tasks into sprints more or less independently from stories.

So i can open a userstory, and let it calculate the remaining amout of hours on that story, and i can use a sprint to plan the optimal use of ressources (testers, programmers, analysts, etc.)

So, anyone out there who has the same requirement and can share best practise a bit?

Kind regards form winter-cold Austria

Daniel

[Nic Brough -Adaptavist-]

This is going to sound harsh, but when you say

"but not having to complete the whole story in one sprint."

That tells me you are not doing anything resembling Agile Scrum.  You might as well throw away sprints, simplify estimates down to non-time-boxed numbers of hours, and treat epics as simple themes to help reporting.

As for sub-tasks, they are, by definition, part of a story.  Treat them as such.  Or split the story so the ones that really are part of the original story are, and the ones that move to the new story are not.

[Nic Brough -Adaptavist-]

And I should really have answered the question too.

Either of your strategies would work, but if you want to do Scrum in any useful way given what it sounds like you are doing at the moment, you will have to use the second one.

Stories should be completed in a sprint.  (I say Stories, but it's any type of issue at the story level - i.e. not sub-tasks and not epics).  That's the whole point of the sprint.  You are telling your product owner that you are committing to delivering a set of them, and you should complete what you said at the end.  If you don't, you need to spend time working out why.  If the answer is "Dave got sick" or " Emergency bug hit us", fine, you have a good answer.  If the answer is "we over estimated what we could do", then you learn from that and lower your commitment in the next sprint.  If you don't, you're lying to your product owner about what you can realistically do.

Jira (rightly) has no way to carry over partial completion.  Sub-tasks are an irrelevance to the sprint as they are part of their parents, and are part of their parent.  It does not matter if you complete no subtasks, half of them 99.9% of them - their parent, which is what you said you would do, is not done.  Only when they're all complete does it matter.

So if you have a case where you are seeing a lot of carry over of issues with sub-task at the end of your sprints, do two things:

1. Don't use sub-tasks, split the issues into smaller more manageable stories
2. Do not over-commit.  A typical starting point is to look at the last sprint, have a look at how much estimate you actually completed and commit to 80% of that.  It's better to deliver what you said you would and pull in a few extras later than fail.  On the next sprint, again, commit to 80% of what you achieved last time (once you've done a few sprints, you'll get a feel for what you really can do)

[Daniel Oberacher]

Thank you Nic and James, interesting points of yours.

I do absolutly agree that the process of cutting the beast is essential. And 100% dedicated and assigned team members is nice.

Frankly speaking I am transforming the team exactly to this currently: we do no further distinguish between run and built tasks. it is all tasks simply and we allow our teammates to enhance (horizontally and vertically) their profession and knowledge by focusing on one topic within our large software solution (taking MS office as the example - on turns herself into an Excel expert while the other one becomes a Word guru... guess you get the point)

as our owners = customers is not one company but 3 banks in the specific case this adds a nother momentum to it. what I have done now is to let the team get use to agile itself and it's methods by letting them work on a physical whiteboard allowing them to try and play what works for them and what does not. once we are very clear here we will check what digital tools offer the most support again (Mira board etc.)

So the tool does no longer dictate how to work. it is the people again, of course covid19 and remote/hybrid working added some painpoints again in matter of synchronization of tasks.

I like the approavh you suggested to further cut down USERStories, although there is a natural size i think where cutting further is just not adding value to the team in matter of planning and organizing its work (for themselves)

BR

Daniel

[James Chan]

I second Nic's comment on his feedback.

If you are not using story points, but using effort hours, leveraging sub-tasks to add up the hours may help, there are JIRA add-ons to identify how much effort planned for each individual for the next time-box.

The side effect is you may spend hours with the team (if you have team of 9, 1 hour meeting = 9 hours total effort used as overheads) to find the right fit. You could also lose a very important thing, the sprint goal. Yes you may filled up 8 hours per person for a 2 week sprint, and you could still fail the sprint goal.

A few things that I did with my team what will set up for success:

1. A stable team capacity is a MUST. I noted you mentioned: depending on what teammates are currently available in the sprint (multi-project organisation still).  I fell into deep wood fighting for resources weekly in a shared resource company. If team players and capacity is not stable, all those power ways such as calculate the team velocity etc will just fail. Player A estimate 4 hours could mean player B's estimation of 6 hours.  

2. If you are truly running Agile Scrum. Ensure Product Owner (not a BA) has a clear sprint goal before sprint planning, 

3. If the team structure is fluid. Try Agile Kanban and slice each story as slim as possible (think of small lego bricks). Slicing stories "vertically" is another big topic that I won't go further in this comment.

Otherwise, have fun experiencing either approach you mentioned Daniel. Run your own "A/B Testing" and let us know which one works better (or if both failed, use the 5 WHYs and find out the root cause rather than treating symptoms :) )