In the scrum process, product owners create epics, features, and product backlog items (the equivalent to user stories). During the sprint planning development, tasks are defined and linked to product backlog items. Everything is visible to the whole team via a Kanban board in the cloud:

Testers create and execute test cases by using the Azure DevOps web portal or Microsoft Test Manager. They create and assign bugs, and code defects and blocking issues can be tracked, just like the following screenshot shows:

Azure DevOps allows you to hierarchically organize your work. You can drill up, drill down, reorder, and modify parent items, as well as use filters in hierarchical views.

Let's now look at the different elements in more detail. An epic can be described as a large user story with a large amount of work. It must be broken down into features and smaller product backlog items to be able to fully understand its requirements, and then be implemented efficiently during multiple sprints:

Features decompose epics into smaller comprehensible parts. They consist of a group of product backlog items that correspond to the detailed expected functionalities:

A product backlog item is a unit of work that has business value and is small enough to be completed during a single sprint. If you cannot finish it in a single sprint, then it has to be considered a feature, and must be decomposed further:

Tasks describe the development or testing work necessary for implementing the expected product backlog item functionalities during the sprint. They are linked to product backlog items for trackability and are able to automatically calculate project advancement.

During a sprint, there are times when a finished task does not entirely do what it was meant to do in the correct way, or it may cause other parts of a system to behave incorrectly. These are called bugs and contain issues that have been raised by testers and/or system users, within the duration of a sprint, which is typically organized in two-week cycles. Bugs may be assigned to be resolved during a sprint, and they are linked to their corresponding product backlog items:

After defining epics, features, and product backlog items, you can do your sprint planning and decide what needs to be done in which iteration. Additionally, the Kanban board provides a great visual representation, for better understanding:

The working capacity for each team member can be defined for each sprint, and a work details report allows you to follow their work achievements in real time:

Furthermore, each work item has a state that changes over time. The state allows you to track work achievements and filter work items, for better understanding and to detect issues.

The following table shows the various default work item states, depending on the work item process:

You can query for work items, create graphs, and publish them to your Azure DevOps project home page. This is a very useful feature if you need to retrieve specific work items or need to get a holistic view of your project.

Now, let's look at the following screenshot:

The preceding screenshot shows a query for work items whose title contains the word game, and respective results are shown in the same window on a lower pane.