Author theguru1974 shares their experiences and concerns when migrating from TFS to Azure DevOps, particularly around how Teams and Areas are handled within the work tracking system.

Overview

The article by theguru1974 details organizational challenges during a migration from on-premises Team Foundation Server (TFS) to Azure DevOps Services. The main focus is on how the concepts of Teams and Areas differ between the two platforms.

Current Structure

  • Teams: Defined as sprint teams; 6 teams in total.
  • Areas: Used to represent a hierarchy of application modules.
  • Teams are not dedicated to particular modules—any team can work on any module.

Migration Challenge

During the test migration to Azure DevOps, it was noted that Azure DevOps appears to require Areas to be nested under specific Teams. This organizational difference potentially disrupts current work allocation and tracking processes, as modules (Areas) should not be team-bound.

Concerns and Questions Raised

  • Is the team-area relationship enforced by Azure DevOps configurable?
  • Can this behavior be controlled at the process template or server level?
  • Should a new custom field be introduced for tracking modules independent from Teams?

Implications

  • The default structure in Azure DevOps might not accommodate organizations where teams are not module-specific.
  • Adjustments such as custom fields or process changes may be necessary for effective work item tracking.

Conclusion

The author seeks insight and solutions to preserve independent module tracking through Areas while using sprint-based Teams in Azure DevOps post-migration.

This post appeared first on “Reddit Azure DevOps”. Read the entire article here