Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Feature as a child to another feature

Last post 08:30 am October 20, 2022 by Ian Mitchell
3 replies
08:09 am October 19, 2022

Hi ,

Background:

I am a product lead in a big fintech company. 

We are using devops to manage the requirements (we also use Product Board to reflect higher granularity items )

We have a complex team structure , which creates many dependencies between teams (not good, but for now thats reality)

We have 3 levels of "product related" item types in TFS - Epics, Features, PBIs.

The different levels are probably similar to other places:

Epics are usually big endeavors that are can stay open for many months.. and describe big domains .

Features (child of epic)  are business capabilities that are delivered in a CI/CD type of a release model

Stories (child of features) are development units which are part of a feature 

 

The Challenge:

1. In this scenario there are two teams - the team who develops the "Business Feature" - Team A, which has some PBIs , and the team (team B) that needs to develop an additional PBI as part of this feature.. 

1. I , as the PO for team B, would like to be able and priroitize the backlog in the feature level, and to not have orphan PBIs floating around

2. the PO of team A would like "team B" PBI to be part of his business feature, to have tracking on the whole feature

 

Question:

1. I suggested to open a feature on team B board which is a child of the feature of team A

2. That enables both parties to see everything in the level of features (and child PBIs) on both boards (Team will see the whole feature tree)

3. Both parties enjoy a clear tracking of the features and PBIs

 

I wanted to know whether there is any methodological issue with this suggestion (i face lack of motivation to go to this solution in the org - as people are not used to it, and raise emotional arguments.. but no proffessional ones

Is there a diff suggestion to resolve the challenge?

 

Thx

Al


09:36 pm October 19, 2022

We have a complex team structure , which creates many dependencies between teams (not good, but for now thats reality)

From what you go on to describe, the reality is that this team structure isn't good enough. There are extensive dependencies, and for some reason you have POs for teams rather than products. This evidently makes value delivery problematical.

I wanted to know whether there is any methodological issue with this suggestion

I can see it might cover the issues up. Is that what success ought to look like? Why not change the reality of how teams and are structured and owned, so value delivery is better facilitated and accounted for?


04:45 am October 20, 2022

Hi - thx for commenting. I completely understand where you are coming from... but i dont have control over everything (working in circles of influence.. the change of team structure will arrive evntually as it is a must.. but big orgs take their time making such changes).

The PO is for a team.. and a team is owning a product. But the products themselves are not distinct enough so one product requires development in other products (so its like in the old world where components were owned by teams). So - i have criticism about the whole structure.. but I will not be able to change that - I am trying to understand what to do with the given situation


08:30 am October 20, 2022

What are you doing to account for the cost of the present situation? From what you describe, there will surely be an impact on value delivery to stakeholders. How are you making the impact of any further delay to structural and systemic change transparent? If change is allowed the time you anticipate, can they afford it?

Rather than fishing for some sort of workaround which covers such matters up, I suggest cultivating a sense of urgency for change. To succeed, that sense of urgency must be created, communicated and reinforced from the top. Find out where your sponsorship for Scrum is coming from, who wants different outcomes, and why.


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.