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.


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?


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.

2 Answers 2


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

  • You got that, because this is what I really strive for "to ensure that the work that is being planned will not overload one discipline too much". And from what you wrote, it really seems that you think we shouldn't regularly estimate ticket for each specialization in story points. Could you please care to tell me why?
    – meridius
    Commented Jul 14, 2019 at 9:12
  • @meridius: I updated my answer with how to use the per-discipline estimates during planning. Commented Jul 14, 2019 at 12:58
  • @meridius: I don't believe in estimates per specialization, because sooner or later you end up in a situation where you want to split one story over multiple sprints. Then you are in the same situation as when you started with separate stories per specialization. Commented Jul 14, 2019 at 13:01

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.

  • What I read in the question is that the teams are already cross-functional, but with I-shaped developers (they can only work in their area of expertise, their "guild"). Commented Jul 11, 2019 at 14:39
  • 1
    @BartvanIngenSchenau Perhaps. But it reads to me like there are hand-offs between different groups that aren't fully involved in the planning and estimation of the work. It's very unclear, but the terminology is confusing.
    – Thomas Owens
    Commented Jul 11, 2019 at 15:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.