Visual Studio Online Process Customization – Update

Back in May, we began explaining our roadmap for process customization on Visual Studio Online (VSO).  In this post, I want to share the progress we’ve made and give an update on our overall plans.

Customization rollout plan
Process customization features will be delivered on the same cadence as the rest of the service, with new functionality lighting up every 2-3 sprints.  Our plan is to deliver customization as simple scenarios that offer end-to-end experiences for managing customizations.  To make this a bit more concrete, here is our prioritized list of scenarios we plan on delivering:

  1. Add custom fields & modify layout for existing work item types
  2. Add picklist and identity fields to existing work item types
  3. Modify the state workflow on existing work item types
  4. Creation of custom work item types
  5. Define business logic and rules for custom fields
  6. Import/Export of custom processes

As Aaron mentioned in May, each of these scenarios will be enabled through simple UI built into the web product so you won’t need to manually make changes to XML or work with clunky tools.  Couple with the UI will be public REST APIs so can hook customization into your own extensions of VSO and automated processes.

Add a field
When we talk to customers about process customization, the most common ask we hear is something like this, “Why can’t I add a ‘Due date’ field to the agile bug?”  At their core, work items are essentially a property bag of name/value pairs so letting users extend this with custom name/value pairs is essential.

The first scenario we’ll deliver is the ability to extend an existing work item in any of our “out of the box” processes (Agile, Scrum, CMMI) and add your own custom fields to them.  We’ll have an “Add a field” experience right from the work item as well as an admin grid view of all the fields defined in a process and referenced on each work item type.

In addition to defining the field itself, the experience will allow you to provide the most common metadata about the field:

  • Tooltip description
  • Default value for the field
  • Should the field be required?
Figure 1. An early UX mockup made with the TFS Storyboarding tool showing what the “Add a field” dialog could look like.

Adding a field wouldn’t be complete without talking about how that field appears on the work item form.  As Aaron previously mentioned, the form is designed for readability and usability.  Fields are shown in collapsible sections on the form and you’ll be able to take control of which fields appear on the form and where.  Coupled with the add a field UI will be a WYSIWIG layout editor where you can manage how fields appear on the form.  When you add a new field, it will appear in a default section but you are free to drag and drop it around to where you want it to appear.

Figure 2. We have some more work ahead of us but here’s how the new form is taking shape.

Shared and Inherited Processes
In our previous customization blog posting, Aaron introduced the concept of shared process and inherited processes.  These are core concepts the process customization story is based on.  The “out of the box” processes (Agile, Scrum and CMMI) are not directly editable by end users – only the product team can do that J.

In order to add fields and customize layout, you have to create an inherited process from one of these existing processes.  Don’t worry, we’ll allow you to import and export custom processes too, but as you can see from our priority list above, that’s the last phase of our rollout.

The process to create an inherited process is super simple.  Choose the process you want to inherit from, right click it on the process page, and walk through the “Create an inherited process” wizard.  The wizard will ask you for a name and description for your inherited process and then it will allow you to optionally migrate existing projects to use it. 

The value an inherited process brings is that it’s a home for all your customization but it also inherits changes from its parent.  For example: if VSO chooses to update the Agile template and add a “Blocked” field to all user stories, the inherited process “super-agile” will inherit the field automatically!  We think this a huge win for customers wanting to keep up with the latest guidance from Microsoft’s processes.

In general, there are 2 operations a user can do to an inherited process: add and hide.  Inherited processes allow you to add a field, add groups/fields to the form layout, add a state, add a work item type, etc.  These are custom to the inherited process.

Hide is best described with an example.  The Fabrikam organization uses the process ‘super-agile’ that inherits from Agile.  Their organization doesn’t do cost breakdowns and they don’t want to see the ‘Original estimate’, ‘remaining work’ and ‘completed work’ fields on their bug work item.  In their inherited ‘super-agile’ process, they choose to hide these 3 fields from the work item form.  Similarly, they can hide the ‘Issue’ work item type because they don’t use that in their daily workflows. 

Finally, existing projects can be easily migrated from using one of the “out of the box” processes to using an inherited process.  This action is fully reversible and no data will be lost in the migration; history of the work item and query results will still show the values custom to the inherited process, but they will not be editable as the fields are no longer valid in the context of the system process.

 Figure 3. Super-agile is an inherited process off of the Agile process.  One project has already been migrated to use it.

This functionality is a couple sprints away from being deployed across the service but hopefully this gives you a sense of where we’re going.  I’m excited to hear your feedback and we’ll be sure to provide deeper insights into the next phases as we get closer to releasing them…

Author: Justin Marks (MSFT)

Justin Marks is a senior program manager in Visual Studio Team Services working on identity management. For the previous 7 years, Justin was part of the agile tooling space where he worked on all aspects of the work tracking system including process customization, the reporting stack, REST APIs, and collaboration experiences including team room, agile tooling and lightweight requirements management. Before working on VSTS, Justin worked on the Visual Studio debugger delivering the end-to-end IntelliTrace experience. During his 15 years at Microsoft, Justin has also worked on as a Systems Engineer during the version 8 and 9 product cycles and on the Windows Shell as both a Software Design Engineer in Test and a Program Manager during Vista and Windows 7.