Azure Boards Summer Update

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

The summer of 2020 has been busy for the Azure Boards team. We are actively pushing out new features and fixing bugs. Over the next couple of sprints, we plan on delivering some exciting new features. Here are some of the things we recently completed and some features coming soon. State transition rules now generally available Back in sprint 170, we released the private preview for state transition restriction rules. During that time we enabled over 100 organizations to use the feature. The feedback you provided was incredible and it allowed us to fix several blocking bugs before it went public. In sprint 172 we are happy to promote the feature to be generally available for all customers. This new work item type rule allows you to restrict work items from being moved from one state to another. For example, you can restrict Bugs from going from New to Resolved. Instead, they must go from New –> Active -> Resolved. You can also create a rule to restrict state transitions by group membership. For example, only users in the “Approvers” group can move user stories from New -> Approved. Copy children Over the years we have gotten lots of feedback from customers on copying work items and the ability to copy both the parent and its children. For instance, when copying a user story, include all the child tasks. In this sprint we added a new option when copying a work item. When selected, the system will copy both the parent and all the children. This works for any work item type in any backlog level. The feature does come with some constraints. First, for performance reasons, you are limited to copy up to 100 children. Second, the "Include child work items" option is only available if the destination is of the same project and work item type. Improved rules for activated and resolved fields The system rules for Activated By, Activated Date, Resolved By, and Resolved Date have always been a mystery. They are only available on system work item types. Plus they are specific to the state value of "Active" and "Resolved". In sprint 172 we changed the logic so that these rules are no longer hard coded to a specific state. Instead they are triggered by the category (state category) the state resides in. For example, say you have a custom state "Ready for Testing" (instead of resolved) in the Resolved category. Now when the work item changes from "Active" to "Ready for Testing", the Resolved By and Resolved Date rules are triggered. This is also true if you have a custom state in the "In progress" category. This allows customers to create any custom state values and still generate the Activated By, Activated Date, Resolved By, and Resolved By fields without the need for custom rules. System work item types on backlogs and boards (preview) With the inheritance process model, there are several work item types that are unable to be added to boards and backlogs. These types are... Process Work Item Type Agile Issue Scrum Impediment CMMI Change Request Issue Review Risk This has been a long time customer pain point, and something we needed to go fix. We are now enabling these work item types so they can be placed on any backlog level. This feature is now available in a private preview for those customers who would like to give it a test drive. To opt into the private preview you can email us with your organization name. Work in progress Here are a few highlights of the work we have in progress this summer. If you have any questions please post a comment or send me a message directly to @danhellem Better PR integration Start using #mention of work items in commits descriptions to better control how the associated work items get updated when the PR is closed. This fixes a long outstanding problem where work items can only be linked or closed. For instance, you should be able to set the work item to "Resolved" by doing something like "Resolved #4451". In the first iteration we will just use the #mentions in the commit messages. Depending on customer feedback, we may update the user interface so you can set the state of the linked work items when completing the PR. Stakeholder board access Today stakeholders can create and modify work items. However, they do not have the ability to move items across the Kanban board. We want to go fix this by allowing stakeholders to move work items across columns. Delivery Plans 2.0 Delivery Plans is a great extension but it falls down for any organization who needs to do real planning over multiple teams. Customers need the ability to see a product roadmap, understand what work is planned and when it will be done, and track dependencies across teams. These are all items we plan to go and fix for our customers with Delivery Plans 2.0.