-1

Brief Background

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:

Scheme to use features and PBIs for splitting by platform

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.

Questions

  • 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?
  • 1
    Scrum means one team, one backlog. You'll need to explore scaled frameworks like Nexus or SAFe if you want multiple teams to work from a master backlog. – Todd A. Jacobs Feb 25 '18 at 20:59
  • You opened my eyes to a new world of Scrum -- thank you! I do, however, see my question as addressing one team (consisting of Android, IOS, and backend) and a single master backlog. But I get your point: if the IOS team lags significantly, I might need to view this as two different teams. – Moshe Rubin Feb 27 '18 at 6:40
1

Does it violate the Agile/Scrum methodology in any way?

There is no Agile(tm) methodology. There is an agile philosophy, described in the Manifesto for Agile Software Development, based on several frameworks and methodologies such as Scrum. The first value of the Manifesto for Agile Software Development is "Individuals and interactions over processes and tools" which encourages conversations. As a framework, Scrum does not highly prescribe how one represents or executes the work to be done; see the section on Artifacts, especially the Product Backlog and Sprint Backlog.

Is this scheme an acceptable one?

Based on those definitions and understanding, the answer is that it could be. It is acceptable by the values and principles of the agile philosophy, and the rules of the Scrum framework. More importantly, as a self-organizing team, experiments to discover effective and efficient ways of working are important.

Does anyone have an alternative solution to track a PBI across multiple platforms without major disadvantages?

Perhaps you are asking the wrong question. Perhaps it would make sense to treat the various platforms as separate products. Perhaps something a solution to re-synchronize the teams; not forgetting about The Mythical Man-Month, as slowing the other team may be an option. "Simplicity--the art of maximizing the amount of work not done--is essential."

Discuss the problem, including the value that finding a solution can provide, with the people/teams involved. Don't allow tools to limit the possibilities.

  • Thanks for your response. (1) For the record, I referred to Agile/Scrum as the methodology, not Agile, but your point is well taken. (2) Thanks for the encouragement regarding experimenting with Agile/Scrum. My company has adapted and improvised process that has enhanced our Scrum experience. (3) Re-synchronizing the team is currently not an option (it could take months to do so). My question is still: can I manage the two platforms in an unsynchronized time fashion, while supporting a single source of requirements, encouraging details reuse, and avoiding data duplication. – Moshe Rubin Feb 25 '18 at 7:24
  • If re-synchronizing the teams/products is not an option, does that mean that this model of operating will continue indefinitely? Context is king, but it seems that you are seeking a validation for your approach to treat the symptom while not addressing the root problem. If so, then using the Feature as a parent to product specific PBIs can work but there will be an administrative overhead, a reduction in Transparency due to Features being less report friendly, and other issues. Experiment and discover. Good luck. – Alan Larimer Feb 25 '18 at 14:23
  • (a) I sincerely hope that eventually the IOS team catches up with the Android team, but this may take months to happen. (b) Consider this: suppose our client app needs to support Blackberry OS (I don't think this will happen <g>). I could create free-floating PBIs for this OS, or I could link them to the original feature item. As for features being less report friendly, in VSTS their templates are identical to PBIs, so reporting is the same. I just need to insert a clear note in the PBI for the user to check the parent feature for the user story. (c) Thanks for the good luck! – Moshe Rubin Feb 25 '18 at 16:29
  • 2
    Hope/Wish in one hand and __ in the other, see which one fills up first. :-) Now I believe I have a better understanding: You plan to use the Feature type to contain what would traditionally be the Story level scope and the Story level will simply specify the platform. The caveat is that no feature will be complete (reporting) until implemented on all platforms. Introducing another platform would be unable to be children of any completed features unless they were re-opened. Treating platforms as independent products then becomes even more effective. Or address the differences to synch efforts. – Alan Larimer Feb 26 '18 at 13:11
  • You're it spot on, I couldn't have summarized it better. :-) Using the feature level allows assigning platform-specific PBIs to a sprint independent of their sibling PBIs. They are, however, easily related to each other via the feature parent. If the PBIs state clearly that the platform-agnostic User Story is in the feature parent, the development team has everything they need to work as usual. Since features are meant to allow spanning projects, backlogs, and sprints, I have no problem with a feature not being marked as 'done' until all platforms are done, or even reopening the feature. – Moshe Rubin Feb 27 '18 at 6:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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