Roll sub-task estimates up through stories to use in allocation decisions during sprint planning.

[Tina Hemenway]

My company is trying to use classic epics and user stories, where each is defined as a slice of user value. That user value includes UI, backend, etc, which means that multiple people will work on a story. (so having a single assignee for the story is not ideal, but ok) For that reason, we are utilizing sub-tasks to define the work for individual developers, testers, etc.

This way, when we plan a user story into a sprint, we know that the entire slice of user value is accounted for in the sprint.

During sprint planning, we are keeping an eye on allocation for team members as shown at the top of the backlog board. We'd like the team to be able to estimate their sub-tasks, and then when the user story is planned into the sprint we can see each team member's allocation updated. That way we can be sure to not over- plan anyone's time.

We have tried to do this with epics and stories, by making the epics be the slices of user value that can be accomplished within a sprint. But then the epics sidebar feature and other properties of epics are lost. We want the sidebar to have items that contain several "user value slice" items that show up in the backlog. Otherwise the epic winds up being misplaced in the hierarchy of issues.

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

You need to be very very careful when doing this, and take into account how Jira sees Agile processes (Scrum is not really an Agile process - I was doing Scrum before 17 people wrote the Agile manifesto, and had had my Scrum processes improved by one of them).  Scrum is a very very very good fit for Agile, but it predates Agile, and although I've worked with it less, Kanban is the same.

I think you have already explained very well, but not quite made explicit, that "user value" is totally different to "estimate"

Your "user value" is a very powerful piece of data - arguably the one thing a lot of teams are probably missing, but could really use when they're ranking their issues.

But as a Jira user, "don't look at sub-tasks".  Jira does not consider sub-tasks to be sprint items, they are simply a part of a bigger issue, where the estimates are counted.  Sub-tasks don't appear in backlogs because they're already there as part of their parent issue.

This cascades down into your "user value" field.  Your issues most/all have a user value - fantastic for helping your developers, but sub-tasks can't - they are fragments of an issue that your end-user would like.

I am still struggling to find a decent analogy for this.  I've tried F1 cars, and "Doing park runs where sub-tasks are different parts of a human", but the closest I have got is "jigsaws".  Your jigsaw forms a picture, it's going to take an hour to build it.  Your sub-tasks are all "put this particular piece in the right place" - you don't estimate or time-constrict that, it is literally "part of the bigger picture"

TLDR: don't estimate on sub-tasks.  Estimate the story, and roll that up. (And get your teams to rank/prioritise by your user value - heck yes - you are listening to your audience there)