We're about to start a new project using Agile (using TFS), and I have a couple of "good practice" questions regarding the product backlog:-

When we first start adding users stories, is it a good idea to put them in (say) a "Backlog" iteration, or just leave their iteration blank? Obviously when the time comes to start work on a US it would be moved into the appropriate iteration backlog.

When breaking an epic down into smaller USs, would I simply close the original epic, as it's no longer required? Or should I create the new USs as children of the epic? (it's then someone's responsibility to close the epic once all child USs have been completed).

Lastly, should the product backlog list all USs regardless of status, or only those that have not been started (i.e in my proposed "Backlog" iteration)?

I realise these questions aren't life-or-death, but it would be nice to know how other people manage their product backlogs so we can organise things properly from the start.

2 Answers 2


I am not familiar with TFS (is that a software tool?) but I can give you some answers based on Schwarber.

1. Story Containers

There are only two containers of stories that you should ever be thinking about, the product backlog and the sprint backlog. Software tools for tracking scrum may allow you to keep around old sprint backlogs for historical analysis and that is ok, but you must close out an old sprint backlog (i.e. make sure everything in it is finished or moved out) before doing any work on the next sprint backlog.

Sometimes there is a tendency to create the next sprint's backlog in a software tool while still in the current sprint. Do not do this. If that future sprint backlog is there, people will try to put stories into it. This disrupts the proper planning process, raises tensions, and confuses scheduling issues.

If you fail to keep proper boundaries between your sprints then you are, in essence, running multiple, similtanious sprints. You are multi-tasking. At the very least the overhead of task switching will slow you down; research indicates that a full context switch in humans, from puzzle A to puzzle B, takes 15 minutes. My experience suggests this drag can be 50% or more of your productivity.

2. Epics

Keep your epics around. Someone asked for this feature, they will probably come back and want to know the status of the epic. That person, department, or customer will be thinking of the 'story' they submitted, now promoted to epic. They won't be thinking about the smaller stories involved and may not even recognize that story Foo is related to their request. The epic is a convenient handle for communication between development and the customer.

Since the epics don't actually get worked on themselves, just the associated stories, the epics move directly from your product backlog to your finished pile.

3. Where do the stories go?

A story should only be in one container at a time. It should start out in the product backlog, move to a sprint backlog, and then be finished. If someone comes looking for their story in the product backlog and doesn't find it, that must mean it is in process or finished.

4. Final thoughts about managing a deep product backlog

Force-ranked order becomes pretty meaningless when you have hundreds of items in your product backlog. Sure, the how you arrange items 20-70 might be fairly meaningful, but who really cares if #300 is before or after #301?

One possible solution to this is to have multiple sub-component backlogs that feed into a main product backlog. For example, you might have UI, DB, Backend, API, Infrastructure, and Technical Debt as your sub-components. Each component backlog might be delegated to a different person for management. A periodic meeting would have to decide what stories to move onto the main product backlog. In order to maintain a proper balance of stories in your product backlog, it is best to decide a priori a guideline (not rule) for the proportions of stories that get promoted to the main backlog. One API story for every two UI stories? How many stories can you take from Technical Debt in comparison to the number of Backend stories you need to take?

This system adds considerable complexity and requires lots of extra coordination. It should only be undertaken when the the product backlog grows so large that the Product Owner can't think about all of the stories at once.


An iteration in Agile isn't so much a container for user stories as it is a minature software release following the SDLC for a small and easily manageable amount of time.

The Backlog is not an iteration, it is essentially a container for user stories, epics and tasks that you do not currently have the time to address in the current sprint. In planning ahead for the next sprint you should re-evaluate the current priorities of items in the backlog, versus the level of effort to deliver each in determining what belongs or does not belong in the next iteration.

Do not plan more than one iteration ahead

This is not Agile and defeats the whole purpose of iterative development in its entirety. Business needs and requirements are typically too volatile to make long term plans on strict software requirements, which is why we keep ourseleves focused only on the current iteration, and the one that we will work on as soon as we deliver this iteration.

If management wishes for long term estimates (based on the current backlog as it exists at this moment) then one can look at the size of the current backlog items to give an estimated date of completion.

Your question about what iteration to put the backlog stories into tells me that you are probably trying to plan your iterations too far ahead.

When breaking an epic down into smaller USs, would I simply close the original epic, as it's no longer required? Or should I create the new USs as children of the epic? (it's then someone's responsibility to close the epic once all child USs have been completed).

An epic should be accepted when it satisfactorily achieves its stated business goal. This is essentially when all of its children user stories have been completed and accepted.

  • I think some confusion is down to the way TFS stores and reports on artefacts. It doesn't have the concept of a product backlog as such - when you ask it to display the PB it simply lists all USs that are not closed, regardless of what iteration (if any) they are in. In my original question I was thinking that by putting them in a fake iteration called "Backlog" it would make it clear to everyone that the US has not yet been started - though with hindsight this is no different to creating a US and just leaving its iteration blank. Nov 12, 2012 at 16:25
  • 2
    @AndrewStephens I would guess your problem is that the default reports built into TFS are disservicing you. This can be pretty easily remedied though because if I remember correctly, it is rather easy to write custom reports for TFS. As far as the backlog is considered, most PM software will treat any unscheduled user stories as backlog. Perhaps you can tinker the report to show these as such.
    – maple_shaft
    Nov 12, 2012 at 16:43

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.