A User Story that crosses components

Question

I'm having a hard time reconciling stories that have a concrete user value and that can be estimated when crossing component boundaries. Assume I own a Game application and have the following user story:

As a User I want to know which friends I have invited 
so that I don't invite the same friend twice to play
this game.

Pretty simple with a clear user value. This game already allows you to invite friends but it doesn't track friends you've already invited. This story asks for that. Now this is a mobile app that connects to a server using REST.

So the problem is that the engineering tasks break into two pretty small tasks. The server needs to make a schema change to track which friends of a user have been invited. The mobile app needs to utilize this to ensure the same friend is not invited more than once.

Also, for fun, assume this is a remotely distributed team and two different resources will be doing the tasks. One that does the Objective-C part and another for the Java server code. Also assume that will not be pairing on the entire story.

So my question is how do most people handle this? There are two different estimates and two different tasks to complete but only one logical story. I only want to track the story. But the estimate (I guess) is the greater of both. If I only put the story into something like Pivotal Tracker then each developer cannot mark the work done as it completes. If I break the story into TWO stories then I have engineering work in my backlog and NOT customer value?

This seems so simple but for some reason I am getting stuck on it, dunno why. As a product owner I want to track the features but since two developers need to work to develop the feature I can't figure out the best way to represent this in pivotal tracker.

Answer 1

This is a pretty classic problem in multi-tier applications. First thing I usually do is split off the front-end part of the work, so something like:

As the player, I would like to disable users that have already been invited so that I can't invite the same user twice.

This sounds a lot like yours - the difference is in the details. This is specifically calling for the UI action of disabling a user. I would do this for two reasons. First, you can ask yourself if you need more than this. Maybe you realize that, for right now, all invites will only ever come from one device and you can add a little bit of client code to track which users you sent an invite to and you never need to check in with the service. This forces you to justify your next user story with deliverable value. The second is just what you said - you can track the work independently.

Let's say, for sake of having another story, that you decide you can't have the client alone track it, because if someone declines and then you want to re-invite them for some reason, you want to know that it's an option again. So here's your next story:

As a player, I would like the list of invitable users pulled dynamically from the server so that I have an up-to-date list of which of my friends are available.

Now, this next part leaves the scope of your question a bit, but I want to point something out. The developer could develop the first story independently and make code that operated completely independently, like I said earlier. However, knowing that the second story is there, it makes more sense to have it his a stubbed data layer that returns back static data. That way, the first story is completable and testable with that static data, you can validate all of the UI interactions, and it's all ready to link up to the real web service when you release it into production.

Edit: After some of the comments, I can see that some additional explanation might be useful. That second story actually encompasses a number of customer/business cases. I can break this into a set of stories that speak to business value, like:

As a player, I would like the game server to update my list of invitable friends when new friends sign in.

As a player, I would like the game server to update my list of friends when a previously invited friend declines or the invite expires.

As a player, I would like the game server to update my list so that I can't invite idle friends.

The list can go on for each case. This does leave some loose work to actually build the service method. Usually I've just wrapped this into the first story, so let's say it's a 4 with the extra work wrapped in and then the next stories are 2's or something like that.

Answer 2

Why would there be two estimates? Most stories in the real world™ are handled by multiple people.

Furthermore remember that estimates are only useful to determine whether a story can be accomplished within one iteration. When in doubt on "how to estimate" something, it is often useful to concentrate on the most basic aspects.

More in general, agile unashamedly favors vertical development and, correspondingly it works best with full stack developers. You may want to allow or encourage your developers to become self sufficient.

Even more in general, one thing I've noticed about agile is that it makes existing problems evident. People often do not realize this and blame the methodology for their team's shortcomings. I don't mean to imply that this is the case in this question!

I think the most effective attitude isn't "Agile doesn't work with my specific problem, how do I fix agile?". In my experience, successful teams are the ones that say "Agile is making a problem visible, how do I fix the problem?"

Answer 3

Organize into feature teams

I have worked with 4 different teams working on a single project. By organizing into feature teams, we avoided this type of problem.

Mike Cohn makes a strong pitch for organizing into feature teams. In fact, the example he is using is that of a California-based game studio:

• "Moving away from component teams is a difficult but necessary step for those who want to adopt an agile project management approach."
• "Rather than organizing around components, each team on a project can ideally be responsible for end-to-end delivery of working (tested) features. There are many advantages to organizing multiteam projects into feature teams."

Fortunately, Chapter 10, Team Structure, of his book Succeeding with Agile is also available online (pages 182 - 189). Hopefully, this will give you a more detailed view into his thoughts.