Should single user story contain estimations for each involved guild in full-stack development team

Question

Problem

We're working in a full-stack development team composed of three guilds (backend, frontend, QA), so as a team we share a single sprint board.
User stories we take into our sprints are written in a way that they may require work from at least one or multiple guilds.

So far the story received single estimation as a composition of votes for all involved guilds. But this way we're unable to tell how heavy the story will be for every single involved guild, which causes us complications in sprint planning meetings and later on in sprints.

Imagine you want to maximize the team effectivity by minimizing down-times of each guild. Because (not every, I know) user story can be worked on in parallel by multiple guilds, you can do that by selecting such stories to sprint where summary of estimations for each guild gives closest capacity of that guild. You mustn't, of course, forget to count with dependencies between stories.

Question

Is it OK for single user story to have estimations for each of involved guilds? And if so, is Jira (cloud) able to deal with that? Does anyone have any personal experience?

Note

We also thought about estimating only sub-tasks, not user story itself, but we rejected that because this would inflate the estimation unreasonably.

Imagine single story with work required by all three guilds. In refinement the story receives following estimations (3 SP: backend, 1 SP: frontend, 2 SP: QA). The guilds agree on single estimation of 5 SP and give this to the user story. Sub-tasks for each guild are left unestimated (with estimation zero).

In opposition when the story itself would not receive any estimation (zero), but sub-tasks for each guild would receive their respective estimations. This would give unreasonably higher SP count (here 6 SP instead of 5 SP in the first case), because you'd have to sum all SPs for each sub-task.

Answer 1

Imagine you want to maximize the team effectivity by minimizing down-times of each guild.

Trying to get more work out of a team by minimizing down-time is called the resource utilization trap. Here is a nice video showing how minimizing down time does not actually increase the output of the team.

The target of a sprint should not be that everybody was busy the whole time, but rather the amount of work that gets delivered with good quality.

Optimizing the amount of work that can be delivered starts with knowing how much work the team as a whole can bring to completion within the timebox of a sprint. And as we are looking at the team as a whole, the most value is in a single, whole-team, estimate.

There is one point where estimates per discipline can be useful, and then traditional estimates in hours are the most useful. That is during planning, when there is a fairly strong specialization within the team, to ensure that the work that is being planned will not overload one discipline too much.
These estimates are not expected to have lasting value, so you might just note them down on a piece of paper during the planning session, or, if you are used to estimating earlier, put in a comment in the ticket.

In this situation, you would first plan the stories according to the capacity of the entire team to deliver work. This will usually be based on their previous track record as indicated by the velocity they reached in the past sprints. After the team has indicated they feel fairly confident that they can fully complete the work that is on the table but they can't complete another from the backlog, you would do a cross-check by comparing the expected availability of the team members to the per-discipline estimates to ensure that the load isn't too skewed. As the team matures, you may see that they start complaining earlier in the planning about a skewed load. In any case, when the load is skewed a negotiation with the product owner can be held to exchange some work to even-out the work more (and if you are lucky, take on more work).

Answer 2

Using terms like "guild" makes me think that you are organized like something similar to the Spotify model. However, what you describe as a "guild" doesn't appear to be consistent with that. In the Spotify model, work is done by a cross functional team, which they refer to as a "squad". A guild is a cross-squad (and also cross-tribe) organization that works on a a particular kind of cross-cutting problem to spread knowledge across the organization.

Typically, in any of the agile methods, you want cross-functional teams that take on the work. This means that the team has all of the skills needed to take an arbitrary piece of work from its initial state to some defined final state without going outside of the team. It's not always achievable - there may be subject matter experts that the team may need to draw on for some work - but it is a desired state.

If you were to structure your work in this way, the team would be able to estimate the effort to deliver the entire work. There would, ideally, be no dependencies outside of the team. If there were a dependency, then that can be considered in the estimate, but I would suspect that it would have a much greater impact on planning the work than estimating the work.

The cross-functional team structure would probably also lead to less resistance from the tools that you are using, as long as you are configured to use them in a way that is designed to support agile software development methods.