Customizing Work Item Types to behave like User Stories in the Agile process - azure-devops

I am currently using devops (cloud) services. I have created a custom Work Item Type (WIT) within an inherited process from Agile. I would like to configure it to behave like exactly like Agile's User Story WIT. By this I mean:
The WIT should be addable in the taskboard view of the Sprints (see first pic, WorkItemTaskBoard).
One should be able to add tasks to the item just like User Story's.
The WIT should rank below features in the WIT hierarchy. This way when it is added as a child of a feature it will be visible in the Backlogs view (see second pic, BacklogChildMissing)
According to my reading I need to export my inherited process as an XML, edit said XML then import the modified XML. I have two issues with this.
A. I have not found any reliable documentation how to perform the above.
B. Although I am using cloud based Devops (dev.azure.com) and am the organization owner I do not appear to have rights to import a process (see third pic, ImportProcessMissing)
Can anyone confirm that I need to perform the export, edit, import the XML as specified above in order to achieve 1, 2 and 3? If so, I would need help in figuring out how to import the process.
WorkItemTaskBoard
BacklogChildMissing - The WIT is not displayed despite being a child of Test Feature.
ImportProcessMissing - Import button is missing.

You can follow the steps like as below image shows to configure the customer WIT in the inherited Agile process.
Create the custom WIT.
Set the custom WIT as the Stories backlog level.
After above settings, in the project which is using the inherited Agile process, you can manage the custom WIT like as User Story.
See below example:

Related

Create task automatically when creating bug in Azure Devops Server

We are using Azure Devops Server. When a bug is created, I would like to create a child task automatically. The task does not need to have any particular properties, it just need to be created with default values and have a default name like "Placeholder" or something like that.
I have already encountered some different ways of doing it, but neither of them seems to be well suited for me:
The extension 1-click-child-links could be used to create a child task by clicking a button in the context menu after creating the bug. This will of course work, but it would be even better if it could be done in the background ensuring the task to be created even if the user forgets to click the button.
As I understand it, using the Microsoft Flow software tasks can be created in the background when creating a bug which would be exactly what I'm looking for, but it would be nice to find a simpler way of doing it without installing a complete software tool.
I've learned that it is possible to hook into different events by using service hooks (https://learn.microsoft.com/en-us/azure/devops/service-hooks/events?view=azure-devops). There are a couple of standard integrations, but neither of them can be used to solve my case. So using this method, I guess I need to develop a custom service creating the task?
Is there a simpler solution to achieve my gool or do I need to stick with one of the solutions above?
As a workaround , we can set Azure Logic App, select When a work item is created"as trigger, and then select Create a work item as action.
Make sure to set the Link URL to the “When a work item is created” URL and set the Link Type to Hierarchy-reverse to create the Task as a child of the Bug item. Please refer to the settings below:
Save the Logic Apps Designer, and then when the bug item is created, the child task named Placeholder will be automatically created.

Azure DevOps: Field with default value containing another fields value

I am trying to find a way in Azure DevOps of displaying a field on a User Story layout that is made up of a URL plus the value of another field on the same story.
We have an external support ticket system where all of our support calls are logged. When the story (or even Defect) is created, we have a field where a support reference is entered.
I want another field that combines a URL and the support reference so it creates a link to the support ticket.
Is this do-able?
Thanks,
Craig
This is achievable. You can Add a custom field to a work item type for an inherited process.
1,First you need to create a inherited process.
Go to Organization settings, From the Process page under Boards, open the … context menu of the process you'll use to create an inherited process, and then choose Create inherited process. Choose the same system process—Agile, Basic, Scrum, or CMMI—that was used to create the project that you want to customize.
2, Add a custom field to an existing work item type for the inherited process.
From the Process page of the selected inherited process, choose the work item type(User Story) you want to add the custom field to.
Select the work item type and click new field or ... to add a field under a group.
For example i add a new field Support Url under group Planning(click Options to define a default value for this field).
3, Apply the customized process to your project.
Click team projects of the process shown as below screenshot.
Open the … context menu for the process and choose the Change team projects… option.
Then you will have the custom field with default value for the work item type in your project.
For detailed steps please check Microsoft Document there.
Update:
Field value made up of a static part, plus another field
There is no direct way or any tool i can find to achieve this. However there is a complicate workaround to achieve this.
You can try creating a service server to to combine the field values and update the workitem field with workitem update rest api, and add a service hook to this service server.
You can refer to the service hook sever provided by Microsoft. Check reate a pull request status server with Node.js

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
​
​

Simplified VSTS Work Item forms for some teams?

Or developers need the Work Item forms as designed for our agile process, but we'd like our regular users to be able to add new bugs and user stories using a simplified form, where a lot of fields are removed and some have team specific default values.
How can this be done?
The closest match I've found so far is templates, where field defaults can be defined, but the form that's used/displayed is still the large cluttered one. Being able to use the template link to land directly on a pre-filled form is a step in the right direction, though.
Azure DevOps allows you to modify your process template and add new work items to your project. You can find the documentation to do this here.
Go to Organization settings for your account --> Process --> Create an inherited process from your process template --> New Work Item Type.
You can then define the fields you want and the layout of the template.
Something else that could be useful in your scenario is the Test and Feedback Extension. This is a simple browser plugin that lets users explore feedback requests and file comments and bugs.

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.