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

Question

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 ?

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.