Implementation planning and reporting with Microsoft Azure DevOps

In the last part of our Azure DevOps series we set up the sample project "Seamless Mobility" and described the requirements in terms of epics and features. This article focuses on the refinement of the requirements in the form of stories and tasks. The goal is to plan a sprint and run it supported by Azure DevOps. We will also focus on communication and collaboration within the team.

Since the backlog already contains epics and features, the details can be described in the form of user stories. User stories have become the standard for describing requirements from a user perspective. They follow the pattern "As <role> I want <target>, so that <benefit>.  
 
In the backlog view, the order of the epics and features as well as the status can be used to identify the currently prioritized items. User stories are now derived for the highest prioritized features. 

Let's have a look at the feature "Basic app development", which contains two user stories. Another story related to the feature would be the user login:

It has proven its worth to establish quality criteria for the formulation of stories in the team, the Definition of Ready (DoR). For example, a story is Ready for Sprint if 

• it has a description
• acceptance criteria have been described
• the priority has been set
• there is an estimate in Story Points
• all tasks have been defined.

In addition, the INVEST criteria (Independent, Negotiable, Valuable, Estimatable, Small, Testable) can be used to define the DoR.

Tasks are used to break down user stories into realizable steps so that they can later be assigned to individual team members for implementation. For stories that are processed over the entire duration of the iteration, tasks provide a helpful means of continuously describing progress. Nothing is more treacherous than an "almost" finished user story, which only has the status "In Progress" for an entire sprint without further measurable intermediate steps. A breakdown into tasks is shown below as an example - Azure DevOps is able to map the hierarchy clearly:

 After the user story and tasks have been described and estimated, the next sprint scope has to be defined. Azure DevOps offers drag n' drop functions and summarizes the sum of the story points (planned effort), the number of user stories (here 2) and the tasks (here 3) per sprint. The capacity of a team results from the sum of the implemented story points from the past iterations. Azure DevOps records this so-called velocity, i.e. the throughput of story points per sprint, in the background and adjusts this value after each further sprint.

This results in a recommendation of realizable story points for the next sprint - which can be displayed in Azure DevOps. Based on the forecast, you can adjust the planning and move a story to the next iteration or add a story to the currently planned sprint if capacity is still available.

After the scope of the iteration has been defined, the sprint can be started. In the sprint view the scheduled user stories can now be viewed and, if available, the tasks can be edited individually. During the sprint, the sprint board forms the central overview of progress and current activities of the team. The sprint board is a helpful support for the daily stand-up meetings, in which each team member reports briefly on the progress since the last stand-up, the plans up to the next stand-up as well as possible obstacles and agrees with the team.

The current sprint progress can be easily visualized using the integrated burndown reports. Various granularities can be used - e.g. the remaining work can be displayed at story or task level:

In additon to the Burndown Chart, which can be accessed directly within the sprint overview, Azure DevOps also offers a very flexible way to integrate additional dashboards and reports. Using a grid, different widgets can be added and configured via drag and drop to meet different reporting requirements.

At the core of agile cooperation is team collaboration. The comment functions for each work item allow important discussions to be stored directly in the work item in Azure DevOps. This offers the advantage that even absent team members can keep up to date on agreed points at any time and that changes to tasks or user stories can be documented / explained.

Many teams now use Microsoft Teams as a platform to support virtual meetings, teleconferences, file storage and chat tools. MS Teams is an ideal complement to Azure DevOps as a central communication and collaboration solution. Through the integration of Azure DevOps, work items can be created directly in MS Teams in Azure DevOps or referenced in the course of discussions.

The Seamless Mobility project also uses MS Teams for everyday exchange. Through the integration of MS Teams and Azure Boards, task information can be easily integrated into the conversation.

After the rough planning of the scope and the creation of an epic or feature roadmap, the detailed planning of the user stories and their implementation in iterations takes place. Azure DevOps provides a comprehensive basis for planning and executing sprints, supported by standard reports such as the Burndown Report. The integration of Azure DevOps and MS Teams allows teams to use their familiar and established communication channels and seamlessly combine them with Azure DevOps.

In our next article, we will take a closer look at the deployments and testing topics before discussing practical features for conducting sprint reviews and retrospectives.