How to create tasks automatically in DevOps using Power Automate?

DevOps is a service right on top of Microsoft Azure that helps in the whole development lifecycle for those who don’t know. From idea, planning, development, quality, and deployment. I decided to create this article to show you how to create tasks automatically, not because it’s hard but because it’s important. We need to save as much time as possible in sorting, organizing, and parsing User Stories so that we can let developers do what they do best.

Image from Azure DevOps site

Azure DevOps It’s an amazing service, and we’ll explore it a lot more but, for now, let’s focus on the planning part.

Planning

Like everything, it all boils down to strategy. DevOps has concepts that you’re familiar with, like User Stories, where teams can plan and break down into tasks with estimations and time spent. The bigger the project, the more we need automation to keep everything well organized.

So let’s think about user stories. Some tasks are always performed, like unit tests, documentation, and others. These usually have defined times and can be adjusted after.

I’ll not go deeper into Agile and other concepts, but I would like to show you how to save hundreds of hours by creating a simple Flow.

The idea is simple. When a new Work Item (User Story, for example) is created, we’ll add the tasks as children.

Create your tasks

Like I mentioned before, we want to create Tasks automatically when a new User Story is created. To do it, we’ll use Power Automate, and the native connector does Azure DevOps.

The trigger looks like this:

Let’s look at the “Create a work item” action.

A lot is going on, so let’s focus on certain parts:

Configuration

First, the configuration part.

We need to define the “Organization Name” and “Project Name.” 99% of the time, you’ll see the ones you have permissions, so this will be an easy configuration. If you don’t, please check your connection of permissions in Azure DevOps because something may not be set up correctly.

The main items for the Task:

1. Title – keep it short and to the point. I would recommend using a verb to start and then the action.
2. Description – what needs to be done. Since these tasks are common for all projects, people will know what to do and keep it descriptive.
3. Iteration Path – in our case, we’re inheriting the iteration path from the “parent.” You can consider an “Iteration Path” as a Sprint, with some caveats.
4. Area Path – the same as above. We’ll inherit this from the “parent.” The area path is a way for the organization to not dwell too much into it. Think of it as a hierarchical way of organizing your Work Items.

The links

Since we’re creating a Task, we need to define it as a “child” of the main User Story. A User Story will have multiple tasks with different estimations that will allow us to develop that User Story.

Here’s where things get interesting:

1. Link URL – This is the link to the parent. We link it using an URL that we get from the trigger.
2. Link Type – There are many link types (related-to, for example), but in this case, Microsoft decided to call it “Hierarchy-reverse.” I can’t say I’m a fan of the name, but it makes sense.
3. Other fields – This is the best part. We can already define some fields that can fill in automatically. In our case, we have the estimations and type of activity configured so that the task is as complete as possible. The estimate is defined in hours, and the activity should be present already in DevOps.

State

Finally, we have the state of the project

1. Assigned To – Who is the person that it’s assigned to? We inherit this from the parent since that’s the person that is implement the User Story.
2. State – The default state is “New,” so we’ll keep it that way since we’ll create this as soon as the parent is also created. Since you can have different states per User Story, I prefer not to inherit from the parent to avoid issues.
3. Tags – They work like any other app or service. You can use one or more depending on the usage that you have defined.

Final thoughts

As you can see, the Flow is effortless, as well as the DevOps action configuration. We don’t need complex Flows to save us a lot of time. If you use DevOps, talk with your team and find areas where you can create tasks automatically. Every time Power Automate creates one; it’s 2 minutes that you save your team. It quickly adds up, so keep these small increments in mind.

Photo by airfocus on Unsplash