Azure Devops Board vs Jira - azure-devops

I am comparing Jira against Azure Devops Board and notices few limitation:
1. Components field
JIRA - Components are sub-sections of a project; they are used to group issues within a project into smaller parts. Components add some structures to the projects, breaking it up into features, teams, modules, subprojects and more. Using components you can generate reports, collect statistics, and display it on dashboards and so on.
To add new components, as shown in the above screen you can add name, description, component lead and default assignee.
DEVOPS BOARD - No component field, even if we can customized to add one, it is just a String.
2. No Issue-Type Prefix Ticket ID
JIRA - We can customized to have an issue key, -. For example : REQ-1313
DEVOPS BOARD - Just a number.
3. Workflow Sequencing
JIRA - We can use workflow properties for changing the order of the sequence of transition buttons. So from "Ready" state, we can either go back to "New" / "In Progress" / "Rejected" but not "In Testing"
DEVOPS BOARD - Seems like we can jump to any state we want.
I'm not sure if I'm misconfigure, but if so, please provide a way to do so, or maybe an alternatives to limitations listed above.
Thanks!

1. Component field
Azure DevOps uses the Area Path field for that purpose. About area and iteration paths (aka sprints), Define area paths and assign to a team
2. No Issue-Type Prefix Ticket ID
I can not understand where is a problem here? Can you describe some example?
3. Workflow Sequencing
You can restrict change of the State field with rules: Prevent reopening work item once closed

Related

Creating an item inside a single board of Azure DevOps from API

For context, I just read this question Creating Issues on Board in Azure DevOps from API
I have the exact same goal, except the solution didn't address it enough in my opinion because it didn't create the element inside the board.
I am using https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-items/create?view=azure-devops-rest-5.1&tabs=HTTP, It works great, however, I cannot send my item in a specific team board, it always end in "Work Items" menu, did I miss a field or something ?
That depends on your board.... as an example, for Agile you have to create User Story, Feature, or Epic.
Additionally, check your team settings (Define area paths and assign to a team)... if it uses custom settings for Area Path, you have to add Area Path to your request body.

Required information on work item, before a ticket is added to iteration

I'd like to make sure, that all required fields in my tickets are filled properly, before a specific work item will be part of the current sprint / iteration.
Detailed explanation:
The work item in Azrue DevOps shall have some required fields like "Problem description" / "Current situation"
The required fields of the work item doesn't need to be filled, if the work item is created and only pushed to backlog
Once the work item will be moved from backlog to current iteration, it shall be checked if the required fields are filled. If these fields are not filled, a movement to the sprint shall be prevented and the user (who wants to add the ticket to current iteration) shall be informed that required fields needs to be filled
Can this be done in AzureDevops?
Can this be done in AzureDevops?
As far as I know, there is no such feature in Azure DevOps can meet your requirements.
In Azure DevOps, we can use the work item rule to set the required value when the work item moves.
This is very close to your needs. However, currently Azure DevOps does not support adding an iteration path field to the work item rules.
So there is no out-of-box method could meet your requirements now.
Here is a suggestion ticket about Add Iteration Path to Rules, you can refer to it.

How to customize Azure DevOps WorkItem Field Microsoft.VSTS.TCM.Steps

I'm looking for a way to add an additional column for test steps in Azure DevOps TestCase WorkItem.
It is possible to add new fields (string / select controls etc) and reorder existing fields on the test case level. But is it possible to customize the Microsoft.VSTS.TCM.Steps Field?
There is no possibility to adapt it in the test case edit view
and the field delete / edit in all fields area is deactivated too
In the self hosted azure devops server 2019 it seems to be possible over tfs power tools / wit export & import. But how to do it in the azure cloud? maybe there is a way over extensions?
It seems you are using XML process model in azure devops server 2019. But in azure devops service, you are using inherited processes model. To customize work item types in inherited processes, please refer to the following link:
https://learn.microsoft.com/en-us/azure/devops/organizations/settings/work/customize-process-wit?view=azure-devops
You can only delete the custom fields, those fields defined for system processes can not be deleted. Steps is a particular field that can not be hide. If you want to customize Steps field, you would need to create a custom work item and customize the Steps field there.

Child work types inheriting field values from parent item

I am working through creating a custom process in Azure DevOps and was curious if field values from parent can be shared with child items.
Here is an example:
Create field 'Custom Field 9' on Epic work type
Create the same field 'Custom Field 9' on Product Backlog Item work type
Create an epic and fill in the value of 'Custom Field 9'
Create a child Product Backlog Item, 'Custom Field 9' is then inherited to the backlog items field.
What I've tried so far is to use a rule on either Epic or Product Backlog Item, however, I do not believe the rules can apply to creation of children processes.
One other option I'm going to try later today is a Flow that detects when a child work item is created and perform it automatically. I'd like to try to keep this contained to Azure DevOps if possible.
Edit: Thought it helpful to mention that we are using the hosted solution of DevOps and nothing on premise.
Sorry to say that as default, there does not such a work item features with "out of the box". But you can use another tool to achieve this.
Like you said, Microsoft Flow, there does not such feature supported while connect with Azure Devops.
But, in addiiton, I think you can do this with writing some custom scripts. And then configure Web hook to trigger this custom events.
Also, here has another tool named TFS Aggregator (Web Service) to achieve what you want. You can set and configure apply certain rules (such as copying fields from a parent item to a child item). And it will trigger after a work item is created or saved.
I know this is very inconvenient, here has an same feature suggest which raised by others. They has the same demand with you. You can vote and comment for this suggestion. When there are enough communities vote and add comments for this feedback, the product team member will take this feedback seriously.
I needed this feature as well, but in it's absence I have got it to work (relatively easily) with an Azure Logic App (for anyone also using Azure)
​Trigger
When a work item is created
Then
​Get work item details using "Parent" as the work item ID to search for
​Finally
​Update the new work item with any field from the parent you require
​
​

IBM create automatically children work items

I work in IBM RTC (Rational Team Concert); the Project Area I own is built on the IBM Formal Project Management Process Template.
I’m looking for a mean to get work items created programmatically;
I do want when I create a Change Request work item, to allow the selection of different teams and from this attribute(s), create automatically children work items Task directly assigned to the right team/member.
How would you recommend to do so?
Although it is not a direct answer to your issue, but I guess it would help. It's more like a workaround more than a solution to your requirement.
The work around is divided into two steps:
Create a work item template from a CR with all its sub tasks included in the work item template.
Create a CR using the previously created template programmatically.
Note: This means that you'll need to create a work item template for each team.