Feature as a child to another feature
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
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?
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
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.