New in Azure Boards Sprint 174

This post has been republished via RSS; it originally appeared at: Microsoft Developer Blogs.

The Azure Boards team has been hard at work fixing bugs and shipping new features. We have a few features that are now generally available and a couple that are private preview. Lets go through all that is new...

System work item types on boards and backlogs

Back in sprint 172 we opened up a private preview that allows you to add other system work item types to your backlog and boards. We are happy to announce that the feature is now out of preview and generally available to all organizations. Adding a system work item type to a backlog level is simple. Just go into your custom process and click the the Backlog Levels tab. Select your backlog level of choice (example: Requirements Backlog) and choose the edit option. Then add the work item type.

Image backlog levels 1

These are the system work item types that are now available to put on a backlog level.

Process Work Item Type
Agile Issue
Scrum Impediment
CMMI Change Request
Issue
Review
Risk

New process audit log event

When it comes to process customization, editing picklist fields are one of the most common changes made. Now an event will be logged whenever the values on a picklist are added or removed. With this new event, organization admins can better track when and who made changes to those fields.

Image audit log 2

Customize work item state when a pull request is merged (preview)

Not all workflows are the same. Some customers want to close out their related work items when a Pull Request is completed. Instead of closing, other customers want their work items to be set to another state like validated or resolved. We should allow for both.

Starting in sprint 174, we have a new feature that allows you to set the work items to the desired state when the pull request is merged and completed. To do this, we scan the pull request description and look for the state value followed by the #mention of the work item(s). In this example, we are setting two user stories to Resolved and closing two tasks.

Image pr 1

The logic works like this..

  • If the value matches a state, then set it to that state.
  • Else If the value matches a state category, then set the work item to first state in that category
  • Else, ignore it and don't do anything

Don't worry, we will provide full documentation once the feature is generally available 😀.

We are excited to see what you think. To start, we are just scanning the pull request description and not including any user interface changes. We wanted to get your feedback first before investing further.

Stakeholders can move work items across board columns (preview)

Stakeholders have always been able to change the state of work items. But when they go to the Kanban board, they are unable to move the work items from one column to another. Instead, Stakeholders would have to open each work item, one at a time, and update the state value. This has long been a pain point for customers and we are happy to announce a private preview this sprint that will enable Stakeholder's to move work items across board columns.

Azure Boards GitHub app repo limit raised (preview)

If you are using the Azure Boards application from the GitHub marketplace, there is a limit to the number of GitHub repositories you can connect to. This becomes a blocker for organizations that have over 100. In this sprint, we changed how Azure Boards connects to your GitHub repos to support well over 100. If you are currently hitting the limit, let us know, and we can lift that limit to unblock you.

If you are interested in participating in any of these previews please email us directly. Don't forget to include your organization (dev.azure.com/{organization}).

REMEMBER: these articles are REPUBLISHED. Your best bet to get a reply is to follow the link at the top of the post to the ORIGINAL post! BUT you're more than welcome to start discussions here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.