How to move from Jira to Azure DevOps

How to move from Jira to Azure DevOps

This article provides details on how one should organize & administrate Azure DevOps projects with a Jira background. This article won't cover how data needs to be exported from one system to the other, there are plenty of articles covering this part on the web.

Definition of Project

The most striking difference between the two tools is what they call a 'Project'. 

In Jira, it is pretty straightforward as the project has the same meaning as the one defined by the business. A project is a business goal that your team has to attain within a limited timeslot. 

Azure DevOps on the other hand is making thing surprisingly complex. The tool merged the notions of Organizations and Projects and the definitions aren't exactly what you would expect. Creating a Project in Azure equals to creating a division in the company according to Microsoft guidelines.

The question is what's the Microsoft's definition of a business project ?

There are several answers.

Microsoft created a very scalable tool where you can map the structure of your enterprise onto the Organization/Projects notions. In a big company, the natural approach will be to manage divisions as Projects whereas in smaller structure, creating a Project for each business project is still a valid (but not recommended) approach. So how do we have to organize ourselves ?

A backlog filter named Area Path

Microsoft introduced a new notion in backlog management : the Area Path. In a few words, the Areas allows you to categorize the backlog elements. 

This is something you can't do in Jira because each project has its own backlog. In Azure, your division has a main backlog root that is then divided into sub-categories where each of them can be a product, a team or ... a project. This makes it even more confusing because we still don't have a precise definition of the Project. However, this is half of the answer, for each project that your division will manage, create an area.

How do we consolidate the backlogs ?

Making all work items visible from a single place is something that wasn't possible with Jira out-of-the-box. Each project has its own backlog, its own team and its own scrum board. That's one of the rare drawbacks that I experienced when using Jira.

In Azure it becomes possible thanks to the hierarchy of the area paths. In the project settings, make the root area path 'include sub-areas' and boom, the division's backlog now makes all work items visible and displayable in one scrum board. Fantastic ? Hum... not really.

Although it can be helpful for a product owner to have a global overview, you easily find yourself flooded with work items that have no meaning out of their context. Let's assume you have an epic named 'Remote control' in 2 of your area paths. Flattening your backlog will display 2 epics with the same name at the same level which goes against clarity. Even worst, you have absolutely no idea of what the user stories are about when you look at them, mixed with stories related to other projects.

Fortunately, Azure includes backlog filters that are helpful to filter by area path and show relevant information only. Two remarks about this:

• it comes back to having 2 distinct projects
• it is probably a bug but using the filters removes the hierarchichal view of the work items which is a pity

What about teams ?

In Jira, again, the notion of team is straightforward. You add all the stakeholders in the settings, assign the roles and you're good to go.

In Azure, again, a Team is not what you think it is. First of all, keep in mind that creating a team will automatically create:

• An area path (you can uncheck this one)
• A dashborad
• A backlog (and hence a scrum board)
• Velocity/Burndown statistics

Each Team has the possibility of defining their own iteration path (e.g. length and start/stop dates of sprints).

Now, you have 2 choices:

• Either this is something that is interesting for your division's structure where you have several teams working on several projects
• OR you have 1 multidisciplinary team working on several projects and you're not intereseted in having extra dashboards, iteration paths,...

So far, I have been working with one single Team in my division but we are already seeing the limitations:

• Navigation in the backlog is really not easy : the filtering by Area Path is working well but you have to be always careful with creation of new work items and ensure that they are categorized in the right area path
• When filtered, the work items order cannot be modified
• If you're looking for the closed items with the filters on, you won't find them
• The overview shown in Plan is completely pointless and you don't have a clear vision of your project's roadmaps

A compromise would be to create additional Teams without a dedicated Area Path and to map them onto the existing Area Paths of the backlog. I really think that it becomes heavy but it might enhance the overall experience with Azure.

EDIT 20/12/2019: We finally created one team per project and we've been using it for a while now. It really makes the navigation easier which helps a lot for backlog refinements. Another good point is that the 'Plan' overview becomes useful because it shows the roadmap for each 'Team' (a.k.a 'Project'). So to conclude, Team is the second half of the definition of a 'Project' for Microsoft Azure

Mapping of the work items

Jira allows the creation of Epics for groups of features or long-term goals and user stories for the tasks to be executed going forward. Each story can be divided into sub-tasks and the completions of all of them trigs the completion of the user story. 

Azure introduced an additional levels to this scheme.

Microsoft's guidelines to map your tasks into Azure are summarized in the following table:

Azure work item	Completion time
Epic	Months
Features	Weeks
User story	Days
Task	Hours

Still confusing, especially when we work in small iterations without a clear long-term roadmap. The time ranges that Microsoft provides is perfectly valid but it tends developers to think with durations and not efforts. That's probably why they've drawn a separation line between Features and User Stories to let management figure out the roadmap and development team focus on the efforts which is the ideal (but unrealistic) approach.

To frame this a little better, here is a more complete table for the mapping:

Azure work item	Alias	Azure work item	Examples
Area Path	Project	Months/Years	Coffee maker robot
Epic	Goal / Initiative / Final Outcome	Months	Deplacements / Grinding / ...
Features	Step / Module / User-facing function	Weeks	One-click coffee preparation
User story	Action / Testable requirement	Days	As a user, I can stop the robot from the mobile application so that I keep control on the coffee preparation cycles
Task	Sub-Action	Hours	Find a nice-looking flat icon for the button

With that said, I see room for improvement in Azure:

• You can start working on Tasks before moving a story to 'Active'
• Completing the sub-tasks do not trig the completion of the user story
• Same goes to user stories and features

Note : It can be confusing at first but Azure proposes a new type of board to have an overview of the on-going activities within a sprint, the Taskboard. I really like the idea because visualizing the sub-tasks in Jira wasn't convenient

Read More