Tracking and prioritizing PBI when is split by platform

Question

Suppose you have a PBI or User Story which can be split by platform like:

"As user I want to read my feed so I can be updated with news"

But that User Story is for iOS, Android and Web, so we use to split by platform and create a different card for each one, but when the sprint finish, and only two of the three cards are done, I can't mark the main card as "Done" (at least I think so) and feels like we are delayed.

There is a similar problem when prioritizing the split cards, because they come from the same main story and we feel it's a time waste mostly when different people are working on each card, so it's impossible (in my experience) to sort by priority.

I'd appreciate your help on how should we manage this topic. Should we drop the main User story and work with the split ones? Should we prioritize the split user stories when it's split by platform?

Answer 1

There are two situations that you need to differentiate:

1. The story was estimated to be small enough to be done in one sprint (along with some other stories) and different tasks were created to implement it for the different platforms.
   In this case, if you are not done for all platforms, your story isn't done and you can't claim its points. This is a normal estimation error that can happen for any story.

2. The original "all platforms" story was deemed too big to be completed at once and it was split to make the work more manageable.
   In this case, it is entirely normal that not all the "platform specific" stories are completed in the same sprint. That was the whole point of splitting the parent story. Heck, they might not even all be planned to be started in the same sprint.
   In this case, each "platform specific" story needs to be estimated on its own and you should forget you ever made an estimate for the parent story. Once the story for one platform is done, those points are earned.

With regard to prioritizing the split stories, that should be based on the value that it has for the business. For example, if it is known/estimated that 60% of your user-base will access the system through the website, 80% is using an Android-based phone and only a handful users have an iOS-based phone, then the logical order from business perspective would be to implement the Android and web versions quite soon (and probably in that order), while the iOS version can go down the backlog much further.

Answer 2

Bart van Ingen Schenau's answer was excellent. I will only add to his response by stating that essentially the original story was too big to be a story and was, in fact, an Epic or Feature. So what you're doing is more in line with what we call "vertical slicing", to create a "right-sized" story that could be completed within a sprint. You mention that "we use to split by platform and create a different card for each one, but when the sprint finish, and only two of the three cards are done, I can't mark the main card as "Done" (at least I think so) and feels like we are delayed."

You seem to be under the impression that, unless all three platforms are ready simultaneously, you could not release. But why not? As Bart says, if 80% of your customer base uses Android, and you can finish that in a sprint, you could release that new functionality to 80% of your customers after one sprint. Therefore, you are behaving in a way in keeping with the agile principle of releasing frequently.

Conversely, if you try to keep large stories and won't release until the whole thing is done, you delay release from 2 weeks to 6 weeks. That runs contrary to the agile principle.

I get the impression that your discussion of "splitting stories" may be driven by the functionality of the application you are using (such as Rally) to track your work. If that is the case, and you are using a splitting functionality native to the tool, be careful to not allow the tool to determine the process. Remember: Individuals and Interactions over Process and Tools. I have seen many times that scrum masters begin to make decisions on how to handle topics like these based upon what their tool does, rather than what makes sense from an agile perspective.

we typically would have created an Epic or Feature "News Feed" that encompassed the three platforms, and individual stories for each platform. If, however, you need to get all the Andriod work out first, and this would leave many "partially complete" Features in the backlog, and for some reason this causes heartache in management, then we would create separate Epics by platform so we could demonstrate progress and completion of those features by platform. That way, we are working in a way consistent with agile principles and values while using the tool's functionality to our advantage.

Answer 3

The first thing to recognize is that it's all about the size of the PBI. If each platform-specific change is small, then you might have just one PBI for the feature and then tasks to make each platform-specific change. That's perfectly reasonable.

If the changes are more complex such that each platform deserves it's own PBI, then your "feature" should actually be a Feature/Epic. Either is inherently "large" and nebulous, and you don't track those as part of a sprint. Essentially, then, you'd just add the platform-specific PBIs to your sprints as you can fit them in. Maybe you can only get iOS done this sprint and you'll tackle Android next sprint. That's fine and in fact even common. That's why you'll see features in cross-platform apps roll out to only one platform at a time, sometimes with months in between rolling out to other platforms. Having these be parented by a Feature or an Epic allows you see that they are related, but not be bound by that relationship, such that delivering one platform is dependent on delivering others.