Our company uses Agile/Scrum as our development methodology, with Microsoft's VSTS (Visual Studio Team Services) being our tool of choice.
We have several teams, including Android, IOS/iPhone, and backend/server teams, all working on our company's flagship product. For historical reasons, the IOS product lags behind the Android product feature-wise, and the IOS team works hard to "catch up" and bring their product up-to-date.
How does the Agile/Scrum process work for us?
As the Product Owner, I typically author a new PBI ("P") for a feature we want to implement in an upcoming sprint.
At the Sprint Planning meeting, the Android and iPhone teams propose the child tasks needed to implement PBI "P". By the meeting's end, this PBI will have one or more child tasks associated with both Android and iPhone.
What's the problem?
Because the iPhone team needs to catch up on older feature still unimplemented in the product, they frequently do not have the time during the sprint to implement their tasks in PBI "P". Alternatively, the state of the IOS product precludes their working on PBI "P" because some other functionality is not yet implemented.
In other words, there is an unrealistic coupling of the two teams together through a common PBI.
At the end of the sprint I have a dilemma: the IOS team's inability to complete their tasks together with the Android team prevents me from marking the PBI as "done". I have the unenviable choice of:
- splitting the PBI, moving the undone tasks to a new PBI
- leaving the PBI as undone for a later sprint
I'd like to split the PBI by platform
I've come to the conclusion that the only solution to tracking the Android and IOS teams without running into the problems mentioned above is to split (or clone) the PBI into two PBIs: one for tracking Android, the other for IOS. Whatever the solution is, it should support a single source of requirements and encourage details reuse.
Possible Methods for Splitting the PBI (none are satisfactory)
There are two methods I can think of for implementing splitting a PBI by platform.
First Method: Make two copies of the PBI, one each for Android and IOS
In this method, the Product Owner authors the PBI, complete with a full description of the user story, to be used to track the Android team. Once completed, an identical PBI is created for tracking the IOS team.
The obvious drawback here is data redundancy: If the user story is updated in one, it must be updated in the other. In addition, any discussion thread that grows in one PBI might not be seen by the other team working on theirs.
Second Method: Use the Epic / Feature / PBI hierarchy
This method takes advantage of VSTS's addition of two 'portfolio backlog' types: 'epic' and 'feature'. An 'epic' is the highest-level backlog, and can contain one or more 'features', which in turn can contain one or more PBIs.
My idea is for the Product Owner to write his/her user stories in a 'feature' rather than in a PBI. This 'feature' will contain the entire user story in a platform-agnostic fashion. This feature should not deal at all with anything platform-specific.
This 'feature' will contain within (below) it two platform-specific PBIs for Android and IOS, as the following diagram illustrates:
The advantages here are that any changes to the original user story will be made in the feature, not within a PBI. In this way, both platforms have only to look at their parent to see the latest-and-greatest user story.
Any platform-specific comments or additions to the user story should be made in the PBI.
In the even that a PBI does not need to be implemented by different platforms (e.g., it is a PBI for the backend/server group) the user story can be written in a PBI, without making use of a feature.
- Is this scheme an acceptable one? Does it violate the Agile/Scrum methodology in any way?
- Does anyone have an alternative solution to track a PBI across multiple platforms without major disadvantages?