Azure DevOps - Change PBI state when PBI is added to a sprint / iteration

Question

I want to set up a rule in my custom Azure DevOps process so that when we're doing sprint planning and we're looking at the PBI backlog with the Planning side pane open, when a PBI is dragged to a sprint, the state of the PBI would be set to 'Committed'.

My first thought was to set up a rule on the PBI so that when the Iteration is changed, set the status to Committed. But the iteration field is not available in the rules UI - as far as I can tell, this is because in DevOps rules are converted to SQL and iteration is an incompatible field type (maybe).

It looks like there was a feature request for this, but it's been rejected by the Azure DevOps team.

I can't help thinking that setting / changing the state of a PBI when that PBI is added to an iteration would be a very common use-case.

Does anyone have a workaround or solution for this? Or is it just a case of having to change the state of the PBIs manually as a bulk task?

Answer 1

Iteration path fields is not included in the custom rule field list. And this requirement has been reported as feature request to the azure devops team:

Allow work item rules to set Iteration Path

Does anyone have a workaround or solution for this? Or is it just a case of having to change the state of the PBIs manually as a bulk task?

For a workaround, you can consider using the extension: Work item form one click actions

You can set the rule in the extension for the target work item type in Project Settings -> Extensions -> WIT One Click Actions.

For example: You can set the triggers and actions.

Then you can modify the work item field and click the target rule once.

It will then evaluate the work item and change the state.

Answer 2

I think this also have to do with the bigger picture, and how DevOps handle and uses status changes. E.g comitted status is used to track cycle times. The intended use is that the team only puts an item into committed state when they actually decide to start working on the PBI in the sprint - not setting all PBIs to committed as a ceremonial thing at the end of sprint planning. You could argue that it is misleading as SCRUM says that the teams commit to a sprint, but that is not what the status is for :). We did that mistake ourselves and ended up with some unreliable cycle times because every PBIs cycle start was at the beginning of the sprint - which is not how to measure cycle times. And this makes sense when reading the DevOps boards documentation where it is actually stated that the intended use is to only put it into committed state when the work is started. And like that, the cycle times are shown as true cycle times.