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.

3 Answers 3


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.

  • Right, these kind of scenarios I can handle (where I can re-imagine "or massage" the story). Maybe it's not the best example story but assume it is a story with a single customer value that should not be broken down but the work will need to cross tier boundaries. Thanks! Feb 6, 2014 at 18:09
  • I can honestly say I've never run into a story that you can't do this with. If there's one you had in mind, I think it'd be a fun challenge to take a shot at it. Past that though, I think it's important to remember that the rules in project management are there to make the process smoother. If they actually complicate the process in a case, don't get too hung up on it. The fact that the story has to be worked by multiple people implicitly indicates that it can be split, but speaking hypothetically, I'd just say "oops, here's a strange one, one of you put your name on it and we'll just move on"
    – Daniel
    Feb 6, 2014 at 18:21
  • Okay, lets take your first story rewrite. Let's say that client cannot keep any persistent data so that disabled state needs to be represented in the database. Really though, can you kind of see that you are trying to rewrite the stories to fit the tiers rather than just the high level customer/business value? It's the opposite problem of what happens when you try to estimate and schedule engineering tasks. Feb 6, 2014 at 18:34
  • Incidentally, the stories did split on tier. The decision was actually on business value though. I updated my answer to take another step in the process and it actually ends up with 4 user stories and none of them feel like "engineering" stories.
    – Daniel
    Feb 6, 2014 at 19:16
  • 1
    Thanks Daniel, my only nit is that a Player doesn't care if there is a game server. They only know the game not how it was engineered. Thanks and I will digest what you've said here. I appreciate your responses and time. Feb 6, 2014 at 19:31

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?"

  • I'm not sure what you are saying. Who said anything about fixing agile? I was just asking about the best way to handle stories with a remote team in a multi-component/multi-tiered environment. That's all. Feb 7, 2014 at 0:07
  • @user1888440: I don't mean to imply that this is the case in this question!
    – Sklivvz
    Feb 7, 2014 at 0:09
  • 1
    Okay, so you are just generally commenting not answering the question. Feb 7, 2014 at 0:11
  • I did answer the question in the other 4 paragraphs
    – Sklivvz
    Feb 7, 2014 at 0:14
  • 1
    @user1888440 to be fair, your question contains the assumption that you should split the work between the two teams in a particular way. You're really only for confirmation of what you already know. Sklivvz answer actually does answer your question, but it isnt what you wanted to hear. Feb 10, 2014 at 21:22

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.

  • I'm a big proponent of feature teams. Just gets a little more complicated when all team members are geographically dispersed. Feb 10, 2014 at 17:56
  • @user1888440 you've asserted that several times but I've found the opposite to be true. Feb 10, 2014 at 21:32
  • @DaveHillier you've found feature teams to be easier when they are all geographically dispersed. That is a new one for me, I have always found colocated teams to have more productive sprint planning meetings, daily scrums, white board conversations, pair programming, etc. Not that an all-remote team can't work but I've certainly never found it to be simpler like you are asserting. Feb 11, 2014 at 19:12
  • @user1888440 agreed, co-located teams are easier, but, feature teams work better than horizontal teams like suggested in the original question. Feb 11, 2014 at 20:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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