When using the Spotify model, there are many different squads, who each own their own product. Now as far as I understand, these products could be interdependant (like services). One way to manage this in Jira (or similar) could be to create a project for each squad (so each squad has their own backlog).

If a bug occurs during a black box test, it might not be immediately clear, which service (product) is the cause of the bug and therefore which backlog it goes to. This leads me to my question:

Where do you report a bug, before you know what service (product) it relates to?


When placing an order in a webshop, there are three different services involved:

  • Ordering service
  • Inventory managment service (stock)
  • Payment service

A bug occur during a black box test, while trying to place an order. It's not immediately clear, what is causing the bug. In which squads backlog should the bug be (initially) created?

Where does the bug go?

2 Answers 2


This is a problematic question to answer because the "Spotify Model" isn't really a model or a framework or anything that would contain an answer to your question. What people call the "Spotify Model" was a white-paper that generalized the approach being taken at Spotify at a specific moment in time. Therefor, there can be no right answer to your question. I can share some insight, but take it for what it is.

First, I went back and looked at the white paper (it's been a few years) and one of the things it contains is a picture of a few of their applications with sections highlighted to show how "Squads" have broken up the product. You'll notice that they are broken up in fairly clear value streams. One has the ability to play music. Another has the recommendations. In this scenario, even black-box testing has a pretty clear place to start. The fact that you are having difficulty finding where to go with bugs may indicate that you are building teams around architectural components, not functionality.

Second, in an agile environment, I'm unsure how you ended up in this situation. The fact that you need to create a bug in some team's backlog suggests that testing is happening outside of the teams. While it is certainly possible that a bug appears well after release and the root cause is an unexpected odd side-effect of another change, if it happens in testing, the source of the change should be very recent and should have very few teams that could cause it.

On that point, to a certain degree, it simply doesn't matter who you ask to look at it. Let's say you have a bug that shows up after a feature has been in production for a year and no change has been made to that feature. Frankly, at that point, anyone is equally qualified to troubleshoot it. The teams should have strong enough connections to each other to rally around the problem, let someone take lead, and they can reach out to anyone they need to in order to fix it.

As it says in the link you shared, Spotify created a people-driven autonomous approach to structuring their organization to support agility. If you can't simply spotlight that the bug exists and then let the teams self-organize around it, then you should probably be looking at what was missed when trying to apply lessons from Spotify.

  • I agree, that we are most likely having these issues, do to a less-than-optimal implementation of the model (or the idea behind it). But for now, what would you recommend doing? Creating the bug where you think it belongs, and then move it, once properly investigated? Aug 3, 2020 at 16:59
  • 1
    Fair enough. Given the constraint, just creating it where it logically seems to go and letting it kove might be fine. You could also try to create a method by which teams make that choice. That would require a shared space that teams look at regularly and say "that looks like it could be ours". Most teams newer to scrum feel pressure to fill the sprint and gence push back on any extra work, so you would also need a balancing motivation for them to actually take on the bugs without being assigned.
    – Daniel
    Aug 4, 2020 at 3:07

I believe the misunderstanding is that the squads do not "own their own product".

Typically, in the Spotify model, Squads will own part of the system or product. Squads are aligned into Tribes. In an organization with multiple, distinct products, I would expect alignment between Squads and Tribes in a way that each Squad or Tribe is aligned with one and only one product.

In Jira, the notion of a "project" best aligns with a product. You can see this in the fact that projects in Jira contain information about components, versions, and releases, which are typically associated with products. I handle multiple teams working in a single product (represented by a project) using a field on the issue. This lets me set up my filters appropriately.

If you are performing black-box testing on a system, you should know which product you are testing. Since you know the product, you should know which Jira project represents that product. The black-box system tester can log a defect against this project, initially without assigning it to the team. The Tribe Lead and Product Owner can review these submitted issues to determine which team is likely best suited to investigate and fix. Of course, it could be a cross-cutting concern that has a dependency across two (or more) Squads, as well.

In your particular example, the "webshop" is a product. However, there may be Squads around the ordering service, the inventory management service, and the payment service. If you are performing black-box testing, you would not know which service the issue is in, but you should know that it is in the webshop and there should be a set of people who can review, triage, and allocate the bug and its solution to one or more of the appropriate teams.

Two things to consider:

First, the Spotify Model may not work. It was described in an idealized way. It was never done as it was described across the organization. The things that were done were done because they worked for Spotify and it was never meant to be copy/pasted into a different organization.

Second, it seems like testing is not aligned to either the Squad or the Tribe. Or, perhaps, it's a separate "black-box testing team" that is part of the Tribe. Either way, it seems like there's a disconnect between the testing team and the Squads delivering the work. I'd want to dig deeper into what's going on there.

  • Interesting take on things. We are currently using the 1 squad : 1 Jira project approach, which may have been a mistake, but you gotta work with what you got :-). By "Black box testing" i just mean anything that isn't captured by automated testing, it could also be user reported bugs. How would you assign them, to the relevant squad? At the next-coming PO-meeting? Aug 4, 2020 at 5:56
  • 1
    @JakobBuskSørensen You can fix the project approach by setting up one project with the right issue types, fields, and workflows and bulk moving from the others into it, even setting a new "team" field and others first. As far as assigning them, regardless of where the bug report comes from, you need a triage process to determine if it's really a bug, what the risk and impact is, if there are workarounds, what the priority is, who the right team to investigate and fix is, and so on. Whether that's at a PO meeting or something else is up for you to decide.
    – Thomas Owens
    Aug 4, 2020 at 10:18

Your Answer

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

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