When I try to add new completed state to user story or task in inherited process of my azure devops project, I get the following error :
VS403093: Team Services currently does not support changes to
'Completed' category. Choose a different category.
I have looked all over the web and it seems like this is the desired behaviour as mentioned in this link, which I think is very weird.
Are there any workarounds?
I want to create a Done state for my work items, and I think that it's dumb to keep only the closed state for all completed work items since Completed fits better with tickets not with user stories in my sense...
As mentioned below, I could modify all the states except for completed
Any help would be appreciated.
Like you said, at this time Microsoft not allow to change or add states in Complete category.
From Microsoft Docs:
Completed: Assigned to states that represent work has finished. work items whose state is in this category don't appear on the backlog and do appear in the last column of the Kanban board. Note that you can't modify states in this category nor can you add states to this category.
If you want the state "Done" you can use Scrum template (in Scrum the complete state is Done and not Closed).
Related
I've been looking at organisation and project settings but I can't see a setting that would prevent users from creating work items in an Azure DevOps project.
I have a number of users who refuse to follow the guidelines we set out for our projects so I'd like to inconvenience them and the wider project team so that they find it better to follow the guidelines than not - at the moment we've got one-word user stories and/or tasks with estimates of 60-70 hours which isn't reflective of the way that we should be planning.
I'd still want them to be able to edit the stories or tasks and moving statuses, but that initial creation should be off-limits for them (for a time at least). Is there a way to do this??
The Azure DevOps Aggregator project allows you to write simple scripts that get triggered when a work item is created or updated. It uses a service hook to trigger when such an event occurs and abstracts most of the API specific stuff away, providing you with an instance of the work item to directly interact with.
You can't block the creation or update from, such a policy, Azure DevOps will inform the aggregator too late in the creation process to do so, but you can revert changes, close the work item etc. There are also a few utility functions to send email.
You need to install the aggregator somewhere, it can be hosted in Azure Functions and we provide a docker container you can spin up anywhere you want. Then link it to Azure DevOps using a PAT token with sufficient permissions and write your first policy.
A few sample rules can be found in the aggregator docs.
store.DeleteWorkItem(self);
should put the work item in the Recycle Bin in Azure DevOps. You can create a code snippet around it that checks the creator of the work item (self.CreatedBy.Id) against a list of known bad identities.
Be mindful that when Azure DevOps creates a new work item the Created and Updated event may fire in rapid succession (this is caused by the mechanism that sets the backlog order on work items), so you may need to find a way to detect what metadata tells you a work item should be deleted. I generally check for a low Revision number (like, < 5) and the last few revisions didn't change any field other than Backlog Priority.
I'd still want them to be able to edit the stories or tasks and moving statuses, but that initial creation should be off-limits for them (for a time at least). Is there a way to do this??
I am afraid there is no such out of setting to do this.
That because the current permission settings for the workitem have not yet been subdivided to apply to the current scenario.
There is a setting about this is that:
Project Settings->Team configuration->Area->Security:
Set this value to Deny, it will prevent users from creating new work items. But it also prevent users from modify the workitem.
For your request, you could add your request for this feature on our UserVoice site (https://developercommunity.visualstudio.com/content/idea/post.html?space=21 ), which is our main forum for product suggestions.
I would like to set a more precise time for starting the sprint in DevOps, currently it allows only dates to be configured.
Is there a way to set a certain start time hour/minutes for a sprint?
For this issue , as Daniel mentioned in the comment, currently azure devops does not support setting the time accurate to the hour/minute for the spirit.
You could add your request for this feature on our UserVoice site , which is our main forum for product suggestions. After suggest raised, you can vote and add your comments for this feedback. The product team would provide the updates if they view it.
Simple answer. Don't move your US across sprints. If you have created tasks for the US or work has started on any tasks in the US from previous sprints, then leave the US in the previous sprint and move the tasks over.
That way you can track which stories are incomplete at the end of each sprint and understand your actual velocity more easily.
The danger of moving unfinished work over is that you may have 90% finished a large story and give yourself a false image of success in your current sprint, affecting future estimations.
I want what change work item state was strict like my work flow (not allow move work items to any state) or shall do warning about incorrect state.
This feature on preview only. You can find documentation here: Restrict state transitions. If you want to test it you should request this feature.
If you are interested in participating in the private preview, please
email us directly with your organization name.
In Azure DevOps, the Bug WIT state workflow includes the Removed state in the Scrum process but not in the Agile process.
We would like to add the Removed state to our Agile process Bug WIT. We understand how to do so, but the fact that it's different gives us pause. ADO typically has good reason for the base configuration, so it would be helpful to know why the difference exists, as well as any info on potential repercussions of adding the Removed state to the Agile Bug WIT.
This is not a problem in Azure DevOps but the standard process
(Agile workflow states). The following are the steps that can
be used for the workflow in the standard process:
User Story (New, Active, Removed, Resolved, Closed)
Bug (New, Active, Resolved, Closed)
Task (New, Active, Removed, Closed)
In Azure DevOps, however, this workflow can be adapted. For this the process must be modified. Here you can also add Removed for a bug type within the workflow.
You can use the Removed state as long as it works for you. You'll be able to update your work items you've set to Removed to another state, or simply do a Bulk delete.
Hope it helps.
Feature cycle time is a very important metric, but in ADO there doesn't seem to be a way to get the State of a Feature to automatically update when the first story moves into Active (or the last child is closed). Does anyone know of a way to have this happen?
No, that will never happen. This area for custom application and solutions. You can try the following:
TFS Aggregator
Write your own solution through rest api: Automation of state changing for Azure DevOps work items based on states of child work items
Use additional solutions: Automation of state changing with Azure Logic App