Requirement management with Microsoft Azure DevOps

Our example scenario will focus on the development of a mobility solution that we as a software development company want to develop. The goal of the project is to develop a mobility platform that allows our customers to improve their short-haul travel experience and combine it with other means of transport along the entire travel journey. In the first year of the rollout, at least 200 scooters should be available in the pilot cities, no loss should be made and at least two additional means of transport should be integrated. The focus is on seamless integration across various transportation providers and easy application handling to maximize the customer experience.

Before we get into the requirement management with Azure DevOps, we create a suitable project environment in Azure DevOps - starting with the project start site. This site serves all project stakeholders as an entry point to get an overview of the project content and project governance. Azure DevOps offers the possibility to create Wiki pages and use them as overview pages for projects, which can be used e.g. for the project description, the goals, contact persons and technical details of the environments. For the project "Seamless Mobility" we have created the following project sites:

The next step is to refine the project goals in the form of epics, features and first, rough user stories. Epics will establish a direct link to the project's goals. Therefore, it is recommended to proceed from the rough (the project goals formulated in the form of epics) to the fine (the assigned features and user stories). This approach offers the advantage that even small-scale requirements can always be linked to the overall project vision.

For our project example, we have defined the following epics:

• E-Scooter Provisioning (everything around the contractual cooperation with an E-Scooter manufacturer, general infrastructure)
• E-Scooter Booking App (the app with which the E-Scooter can be booked. Combined bookings, e.g. with a train ticket, should also be possible)
• Integration of other transport providers (technical integration with other booking platforms such as DB or Car2Go App)

Below you can see a possible structure based on the defined epics, which are refined step by step into features and then into user stories.

When describing requirements, we recommend using a consistent structure. This ensures that requirements at all detail levels (Epic, Feature and User Story) are described completely and comprehensively. Templates such as the Epic Template in SAFe are suitable for this purpose. Azure DevOps offers the possibility to easily save templates for the formulation of your work items.

From now on if you create a new Epic, Feature or other Work Item you can access your previously stored templates for the respective Work Item Type at any time:

Basically, it can be said that it has proven itself not only to link high-level requirements with project results, but also to focus on the benefits for the customer and the product at all item levels. We recommend not to do this for all work items and item levels in full detail - the reasons for this are to ensure the ability to react to changes in the project and changes to the product scope and to avoid time-consuming detailed discussions or estimates for user stories and features that may not be implemented at all in the course of the project. 

Once requirements have been described and analyzed in terms of epics and features, rough estimates are needed. The recommended estimation methods are the expert estimates and relative, abstract estimates (e.g. T-Shirt sizes) that relate the epics and features to solutions which are already implemented. Relative estimation techniques have the advantage that they can often be performed much faster than classic estimates. By using abstract sizes, such as T-shirt sizes, the missing details and the associated uncertainty of the estimate at Epic or feature level are considered. However, the estimation is precise enough for an initial estimate and prioritization. When using abstract estimates, it is important that the team agrees on a common understanding, e.g. S <= 4 weeks, M <= 8 weeks, L <= 16 weeks. 

In addition to an initial cost estimate, we also recommend estimating the business value in order to be able to compare cost and benefit. Azure DevOps already offers many useful fields for entering planning details. A custom field for entering a rough estimate in the form of T-shirt sizes can be easily added.

Once the Epics and key features have been formulated, roughly estimated and prioritized, a high-level roadmap can be created. Azure Marketplace offers a variety of enhancements for Azure DevOps (often free of charge). These include the "Feature Timeline and Epic Roadmap" extension, which makes roadmap planning quick and easy.

Azure DevOps provides an intuitive and yet versatile user interface to support agile requirements definition and analysis. Through the targeted use of extensions, many use cases can be realized quickly and easily, even without a large budget.