Cars Island – backlog structure and definition - part 12

Introduction

In my first article, I introduced you to Cars Island car rental on the Azure cloud. I created this fake project to present how to use different Microsoft Azure cloud services and how to their SDKs. I also presented what will be covered in the next articles. Here is the next article from the series where I would like to discuss how to build the backlog for the Cars Island solution.

Below I present solution architecture:

Cars Island project is available on my GitHub

Backlog and roadmap

It does not matter what kind of solution we build and what Azure cloud service we are going to use. The central place for managing implementation state and collecting requirements is crucial to make sure that our project is in a good condition when it comes to timelines and agreed functionalities. This is why for the Cars Island project I have created a product backlog using Azure DevOps Boards. If you would like to read more about Azure DevOps functionalities, please check this link.

In the Cars Island solution, there are functionalities like:

1. Displaying list with all available cars
2. Creating reservation for a specific car
3. Sending enquiry with attached file

Features mentioned above should be implemented in both applications - Web API and Web Portal. Of course, we have to also implement integration with the database for instance, or integrate with SendGrid to send reservation confirmation.

Backlog structure in the Azure DevOps

In the Azure DevOps in the Boards section, there is a tab called Backlog:

This is the place where we can define our product backlog and collect details about features and implementation state.

This is the backlog I have created for Cars Island:

As you can see there is a specific structure created (I use Agile process for my project in the Azure DevOps):

1. Epics
2. Features
3. User Stories
4. Tasks

If you are interested in different processes available in the Azure DevOps, here is a good source of information.

I used Epics to define high-level goals and parts of the system:

1. Cars Island Azure cloud infrastructure
2. Cars Island Backend Services
3. Cars Island Web Portal

Now you can ask if this is one, the best structure. The answer is simple - no. Different solutions can have different structures and functionalities. This is why you should try to create a backlog structure to make it easier to manage, find and control the implementation of specific parts and features of the solution.

Under each Epic I have defined Features. Example: Cars Island backend services can send reservation confirmation emails to users.

Now under this Feature I have defined User Story: As a User, I want to receive an email confirmation that my car is reserved.

Under User Story there are Tasks:

1. Create Azure Function template with Azure Service Bus Queue item trigger
2. Integrate Azure Function with Azure SendGrid C# SDK to send emails

Each backlog item has its state and person that is responsible for implementation (in the Cars Island the only person was me):

Iterations

One of the great functionalities provided by Azure DevOps is related to iterations. We can decide which backlog work items will be implemented first and when the rest of them will be implemented. Iterations can be defined under project configuration in the Azure DevOps:

As you can see we can also set dates for these iterations. Once iterations are set, we can decide which User Stories we are going to implement in each iteration:

Once you set iterations, you can open Sprints tab and see all the User Stories for the specific iteration:

Queries

One of the very helpful features are Queries. With Queries we can filter work items in our backlog:

This can be helpful when we want to quickly filter out some specific work items from our backlog without changing its structure.

Dashboards

Dashboards in the Azure DevOps help you display some different details about the project condition in one place. You can add multiple widgets. In the Cars Island project I defined widgets to display information about releases:

Of course, you can add more widgets if you want and customize the dashboard. You can also create multiple dashboards.

Wiki

Wikis in the Azure DevOps can be helpful when it comes to collecting information about implementation details, architecture and decissions. For the Cars Island I created Wiki where I store information about the architecture, and informaton about deployment scripts usage:

Cool feature is an option to keep Wiki in the GIT repository. Using it in this way we can review the proposed changes before the will apprear officially in the Wiki:

Summary

In this article, I described how to use Azure DevOps to create product backlog and organize work. Functionalities like dashboards and wiki can be really helpful to collect information about the project. Source code of the Cars Island solution is available on my GitHub so you can see all implementation details. If you want to learn more about Azure DevOps, I recommend checking official documentation. I also encourage you to read my other article called Release notes with Azure Functions and Azure DevOps where I showed how to publish release notes to Wiki.