Ever since the inception of Team Foundation Server (TFS), there has been a need to harmonize its usage with ongoing portfolio management efforts by a PMO (Project Management Office) team going on in bigger companies. In the beginning, the only out-of-the-box way of integrating with tools used by PMOs was to use the Microsoft Project integration, which allowed a backlog to be managed as a project file.
Later Microsoft introduced the integration of Project Server with TFS 2010 which enabled true IT portfolio management capabilities by the combined TFS/Project Server product: TFS would give you visibility into the Agile software development piece within a larger application portfolio that included project-driven or waterfall projects as well, and other non-software development IT projects would be managed directly with Project Server.
However the solution has always been complex to maintain, and smaller to mid-sized companies tried to use just TFS to manage their application portfolio, ignoring Project Server altogether. Since TFS was not built with portfolio management as a baseline requirement, adapting it to manage a larger application portfolio requires trade-offs. One of the is that unless you are using some third party integration, you need to use a single team project. If that is possible in your company, then it works really well.
Other limitations:
- All teams have to use the same process template: either Scrum, Agile or CMMI, whereas before the idea was to let the teams decide how to self-organize, as long as they provided some rollup data for the PMO.
-
Access to each team backlog has to be managed at the area path level.
-
Iteration (Sprint) management becomes more complex if teams are not aligned, with different paths that have to be assigned to a team.
-
The user interface becomes unwieldy with many dropdowns having hundreds of repos, builds, releases, etc. This has been minimized by adding the ability to favorite your most used items, which always show on top.
The idea of using a single team project to manage a portfolio of products has been around ever since TFS was introduced, and was made popular by Greg Boer’s post TFS vNext: Configuring your project to have a master backlog and sub-teams, based on Microsoft’s own experience of using TFS.
After 2017, the Azure DevOps team has discontinued the out of the box integration with Project Server. It makes sense as Project Server is, to Azure DevOps, just another third party, and it now integrates as other third parties do: using a connector.
Since 2010, TFS then VSTS, and now Azure Boards have been evolving features which have increased its portfolio management capabilities, such as cross-project queries, including being able to move an item from one team project to another, and dependency management.
However, when going through the Portfolio Management article in Microsoft’s Azure DevOps documentation, most users do not realize an underlying assumption that is not mentioned in the article: you still need everything in a single team project, both the management and execution backlogs. The same assumption is used throughout the documentation, such as the Agile Culture article, or the Scale Agile to Large Teams article.
One option for a company would be to emulate Microsoft’s Agile culture, and have teams create and manage their own Stories or PBIs, as suggested by the Line of Autonomy below. In this way the top level with Epics and Features can reside in a different team project, with Stories or PBIs in each individual team project.
The caveat for doing that is that although the relationship between Features and Stories still exist, the latter ones are not shown on any Boards or Queries in the original Portfolio project. That allows for a true separation of concerns between Management and Teams. Smaller companies might want to manage Stories together though, and therefore this option won’t work.
For companies that want to use separate team projects, and still do portfolio management, the documentation suggests using Delivery Plans. It works as a graphical query of work items, and it is useful when comparing timelines of User Stories and PBIs across teams. It does not however extend a Feature or an Epic to the sum of the iterations of the contained User Stories: it requires both high level items to be assigned to an iteration or sprint, which goes against normal usage of both, where Features and Epics are delivered across many sprints. Notice that the following picture from the documentation has all Features spanning just a single Sprint. In this view the item called “Change initial view” is being moved from Sprint 50 to Sprint 51:
More recently, the introduction of Feature Timelines has fixed this issue as it allows Features to span over several sprints, but it does not work across team projects:
A compromise for these limitations, while they are being worked out by the Azure DevOps product team, is to keep all the work items in a single team project, and have Repos, Builds, Releases and Packages/Artifacts in separate team projects. It is possible link Stories and Tasks to Code commits/Check-ins, Branches, Builds and Releases by referring directly to the work item ID. You will however have to use the same process template as mentioned before.
Having now understood the limitations of implementing Portfolio Management out of the box, you can decide between one of the strategies above or to use some 3rd party extension to enable it. I will cover that in the next blog post.
