How would you organise a backlog item that is planned to change in future releases?

I've got a requirement that states that: In release 1 users can open content from local machines. In future releases users can open content from remote servers, FTP and web streams.

Is it typical to just create 2 backlog items to describe that requirement. Then just assign the enhancement to a future release?

(Using TFS for any contextual answers)

  • You'll find that User Stories and Features rarely have a 1-to-1 relationship. In your case, you currently have 4 User Stories for 1 Feature (Sourcing Content). A Feature will grow naturally over your sprints. Any changes to this Feature will be logged as User Stories, which are manageable units of work.
    – MetaFight
    Commented Aug 12, 2013 at 12:17

3 Answers 3


That is not one requirement, but 4 requirements. One of the characteristics is of a good requirement is that it is cohesive: it addresses one, and only one, functional or non-functional characteristic of the system. I'd enumerate each of these as separate requirements or user stories to promote traceability and verification:

- Users can open content from local machines.
- Users can open content from remote servers.
- Users can open content via FTP.
- Users can open content via web streams.

Now that you have four user stories, you can treat them as four separate entities, with their own estimates, their own priorities, and so forth.

A release in which to deliver the feature is not a requirement of the system, but a measure of priority, so the story to be able to open content from local machines is placed ahead of the others in the product backlog (probably near the top, so it would be in an early sprint). The others can be prioritized where they fall with regards to other functionality.

The separation also promotes better relationship from the requirement/user story to the test cases that verify the functionality and gives the customer and user the ability to prioritize the four modes of operation in the event you can't deliver them all in the same sprint.


Yes, definitely have different User Stories for the two different features you've described.

User Stories are better off as small as is practically possible, so long they are individually testable, which each of those things sounds like it is.

In fact, even if you weren't planning the 2 features you describe above to be in different releases, I would still have 2 User Stories.

The only challenge this introduces is that neither Scrum nor TFS include a strong way to manage any dependency that doing Story-2 has on Story-1 having been done first. To manage this, when using TFS my team records on the Story-2 Work Item that Story-1 has to be done first. We also create a link between the two User Stories in TFS, although it's easy to overlook this in the Visual Studio TFS UI.

  • Thanks for the TF related comment. I've done a bit of research around their concept of "Features". It seems they're a reasonable way to group Stories that will occur over multiple sprints. I've added the initial requirements as 4 separate stories within 1 feature "Open content from a variety of sources".
    – bencoder
    Commented Aug 12, 2013 at 13:12

User stories aren't descriptions of the final product being built. They describe units of work. Or, perhaps more accurately, they are a placeholder for a conversation about a unit of work. A story defines what you want built for the current iteration.

If you know you are building a feature over time, the story you work on now will only describe the feature as you want it by the end of this iteration. If the feature will evolve over time, you will need a story (or more) for each phase of its evolution.

  • Tempted to -1 for your first sentence. Of course user stories are descriptions of the final product! They serve zero purpose if they are not. I think you mean something different from what you've said.
    – Peter K.
    Commented Aug 12, 2013 at 12:01
  • @Peter K. What do you mean? I would tend to agree. The user story is a record of a user requirement. It will spawn discussion. And there is no guarantee that the final system will implement the requirement as originally envisioned by the user. It could be that the store is closed off immediately but that a collection of other stories (which better map to units of work) are created.
    – MetaFight
    Commented Aug 12, 2013 at 12:12
  • "Could be" and "aren't" are two different things.
    – Peter K.
    Commented Aug 12, 2013 at 12:17
  • 1
    I guess "aren't" could be changed to "aren't always." But that's getting a little pedantic, no? I think the important points here is that User Stories are convenient units of work and shouldn't be considered synonymous with Features. A Feature will most likely be implemented by many User Stories, and a User Story (even if implemented) may not reflect the final state of the system if subsequent User Stories have superseded it.
    – MetaFight
    Commented Aug 12, 2013 at 12:21
  • @PeterK.: the stories as a whole represent the final product, but any single story does not necessarily reflect the final version of a feature. This question is a good example: we need capability X now, but will need to enhance that to support Y later. The story for X won't necessarily represent the final product. Commented Aug 12, 2013 at 13:21

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.