I had been reading on structuring VSTS. The guideline on structure of projects isn't very clear.

Our scenario is that we have lots of projects and only a small team of 3 developers, 2 testers and 2 support people. Now usually VSTS(TFS Online) suggests adding a VSTS PROJECT for each project but we all work randomly on different projects, sometimes on 2-3 projects in a 2 weekly sprint. So handling X numbers of sprints for N number of projects is going to be a nightmare.

Hence in these circumstances approach I am suggesting is as follow:

  • Project 1 (Epic)
    • Release 1 (Epic)
      • Feature 1
        • User story 1
          • Task 1
          • Task N
        • User story N
      • Feature N
    • Release N (Epic)
  • Project N (Epic)

Is it wrong to put all projects in one VSTS project and then create nested epics ?

1 Answer 1


Whatever works for your team is just fine, of course. But there are a lot of considerations.

First, VSTS (or Azure Boards, as it's called this year) doesn't naturally support the nesting of epics within epics. It may be possible to attach one through parent-child changes, but this will be a major pain. VSTS just isn't designed for the level of hierarchy you're imagining.

To make your structure fit, I would change your "Release 1" epic into a Tag (that can be applied to any object in the hierarchy).

If you are only using VSTS for backlog management, that will work. However, if your team is using Repos and Pipelines and all the other modern change management features of VSTS, you'll need to have one project per project (because they have separate code bases).

In the end, my advice is to have one project per product. Over the long run, I suspect you'll run into enough problems that you'll end up having to do a painful migration later.

  • +1 and ta for your answer, there are few things which I am not able to understand correctly e.g. how project is related to releases and pipelines, we can create different releases and pipelines for different templates for different types of solutions in a project Feb 12, 2019 at 14:05
  • I'm a PO type myself, so not best person to talk about Pipelines. They're used in the continuous integration/delivery area to test integration builds and automate aspects of deployment. RE: releases, you can think of them as being a collection of features being delivered after N sprints. So you could tag your features (or stories below them) with a "R1: Dashboard" tag and then easily see what makes up that release.
    – DPH
    Feb 12, 2019 at 14:46

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.