Managing requirements for large projects can be a daunting task. Typically for Enterprise scale projects there could be thousands of requirements from high level visions or business requirements right down to detailed system requirements spread across multiple teams. Keeping track and managing the relationships of these requirements is crucial to many businesses, especially those that are subject to regulatory institutions. In the past managing complex requirements in TFS needed some special customization work that did not always satisfy the needs of the project stakeholders.
In the latest edition of TFS 2013, Microsoft has met this challenge head on with the whole new approach to managing requirements in the enterprise with 'Agile Portfolio Management'. In the following post I'm going to explore how we can customize TFS 2013 to better match your organization requirements management process to help the adoption of TFS in the organization.
When you first open the new Backlogs page in TFS 2013 you will notice some changes. Most notably a Features work item was added to the Backlog Items section.
The Features work item is used to capture the high level business requirements that might be too large for a single team to jump on or might be too vague to start implementation. From there the Features would be broken down into actionable Backlog Items that can be assigned to the teams. So basically this provides a mechanism to maintain the business level requirements and logic behind the Product Backlog Items in the system for traceability purposes that will be needed later on in the project.
Now this looks promising but what if you requirements organization is more traditional with more levels. For example many organization have: 1) Customer (or Business) Requirements, 2) User Requirements and System (or Functional) Requirements. Also what if I wanted to see the backlog in the a hierarchical form?
The good news is that this can all be customized and represented in the backlog. I will show you the approach of achieving this goal without going into all of the details.
1) Lets get started by creating some work items using WITADMIN. We are going to create 3 work items based off the Feature work item so we will simply create copies of the Feature work item and rename them to: "Customer Requirement", "Product Requirement" and "Functional Requirement".
2) Once again using WITADMIN we will create the different categories for each of the new work item types.
4) Once the categories are set up we will need to set up the relationships between the work items (portfolio hierarchy) so that our new backlog looks nice in the web access for TFS.
5) Now we are ready to start setting up the backlog and getting some data in there.
When we refresh the Backlogs page we will see some changes right away. Note on the screen below the additional levels of requirements added.
By default when the Customer Requirements backlog is displayed it will only display a flat list of the customer requirements. On the top/right side of the screen there is a view selector that is used to display the depth and hierarchy of the requirements.
Now if you select the Backlog Items from the View selector your Backlog should look something like this:
Voila, now we have a tree view of our customer requirements right down to Backlog Items. The depth of the view can be adjusted depending on who is viewing the page as we could only look at any of the levels of requirements on their own. Teams will be more interested in Functional Requirements and Backlog Items, but if they are interesting in learning about the business drivers behind the project the information is readily available.
In future blogs I will talk more about how to organize TFS to help scale this Portfolio Management across many teams for large projects as well as tracking and reporting at the different levels of the project.
Enjoy!
