Skip to main content

Devs from other teams working on our backlog, how to track?

Last post 04:58 pm August 30, 2023 by Jacek Markiewicz
5 replies
12:28 pm August 25, 2023

I've gotten into a situation here where I am not sure how effectively advise. 

We have 3 teams, each with their own backlog (but is one Product overall), it was split this way prioir to me joining and the application is different enough for there to be separated backlogs and teams. 

The issue I am needing help with is this: developer from team A, works on PBI belonging on team B's Sprint Backlog (because he was an SME in that area). PO doesn't know how to make this transparent back to team A, do we create a PBI over in team A instead to reflect his efforts? Or do we simply add his name opn the PBI within team B? 

 

Hope this makes sense. 


01:48 pm August 25, 2023

Hi J B

Lets pretend team B is their own company.

How would team B handle this backlog item where the apparently need outside expertise for?

The other way around if team A was a company on its own and some outside request came to make use of the expertise of this single developer.


02:00 pm August 25, 2023

If you have one product, why do you have more than one Product Backlog? The Product Backlog is supposed to contain a list of all of the things needed to improve the product. If that is split into three backlogs for three teams, then you lose that visibility and transparency into the work. Product Backlog Items may have various attributes, so you could add attributes to indicate components of the system or value stream(s) supported by the work. If you use electronic tooling, you can use this to visualize the entire ordered list of the Product Backlog, but also to focus on subsets based on attributes.

However, you could also rethink your definition of "product". Are you absolutely certain that you have a single product and not three products? If you have one product, you can combine your Product Backlogs, use attributes on Product Backlog Items, and look at frameworks like Nexus or LeSS to scale Scrum practices across the three teams. If you have multiple products, then you can decouple these teams and remove some of the dependencies.

If this is a problem of teams and skill distribution, then that is an area to invest. If a team is missing a skill or doesn't have redundancy in a particular skill that is needed to work on Product Backlog Items allocated to that team, then the teams can look to solve that particular problem. There could be opportunities for cross-training or even people moving across teams. The teams themselves should be involved in making these decisions and a retrospective is a good place to have them.


02:36 pm August 25, 2023

PO doesn't know how to make this transparent back to team A

That's hardly surprising, if they have separate Product Backlogs for the same Product. Transparency over the work, including any dependencies, has been lost. Why isn't the Product Owner establishing that transparency by means of a single Product Backlog?


10:39 pm August 29, 2023

Basically, I think the behavior needs to stop. Here's why.

I am making a couple of inferences here, let me know if I'm wrong. 

It sounds like the three teams work on separate portions of one product. This is usually done in two possible ways. 

The better way is that the teams own a portion of the Value Stream. Let's use "book a flight" metaphor as a model. So perhaps team A owns the landing page and flight search functions. And team B owns reservation payment processing, billing etc. The team C handles notifications, check-in and reporting functions. They are somewhat independent but may have to be aware of integration points. 

The worst way is that they are component teams, so there are loads of cross team dependencies, coordination and impediments. Let's assume that is not the case. 

So, Developer Tom from team A used to work in the area of Team B and is a SME. 

Now, he is on team A and the developers on team B are not as knowledgeable. 

This may indicate a failure to perform Knowledge Transfer and cross training. I would investigate and see if that is a process improvement opportunity. 

Meanwhile, when Developer Tom "helps" with team B, dose he get praise for his "heroics"? Is the Product Owner supportive and encouraging? If so, is Developer Tom incentivized to continue to behavior?

How can the Developers on Team B develop subject matter expertise if their work is being done by Developer Tom? 

Would it not be better for Developer Tom to dedicate time to training Team B developers so they acquire the expertise?

And if Developer Tom is on team A, shouldn't he be working on PBIs for Team A

Is the value delivery of Team A being reduced so that Developer Tom performs his heroics on a different team? 

So, I tend to consider how to get Developer Tom to stop doing the work on Team B, and how to increase Team B's skills, rather than "tracking" developer Tom's shenanigans. 

 


08:06 am August 30, 2023

PO doesn't know how to make this transparent back to team A, do we create a PBI over in team A instead to reflect his efforts? Or do we simply add his name opn the PBI within team B? 

Can you share what PO wants to make transparent? Is it just about having visibility of what is that developer doing for the sake of control? Or there is a need for dependency management between the teams? In any case, the developers are the ones to manage their work and make it transparent during the Sprint, not the PO. 

If this is about making the Product Backlog transparent, then, as already mentioned, the PO needs a single Product Backlog to be clear and transparent to everyone.  

Then, during the Backlog refinement, each team may have the PBIs pre-assigned. Those PBIs will form some sort of team Backlog. But it should not be confused with a single Product Backlog.

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.