Work items in Visual Studio Team Services can be customized to meet the needs of your individual organization. Today, project administrators can add/remove fields to a work item form, change the way fields are displayed on a form, define states that your work item can move through, and define your own custom work item types.
This blog post gives you a sneak peek at next set of customizations that we plan to bring to Team Services.
As always, the timelines and designs shared in this post are subject to change.
| Planned date | Feature |
|---|
| Q1 2017 | - Add custom backlog levels
- Improved navigation of process customization
|
| Q2 2017 | - Define business rules for work item types
- Add identity fields to work item types
- REST API support for customization
|
Custom backlog levels
When you create a project with any of our processes (Agile, Scrum or CMMI), each team gains access to one product backlog (Stories, Backlog items, or Requirements) and two portfolio backlogs (Epics and Features). Small organizations typically find these two portfolio levels sufficient for their needs. However, large organizations have expressed the need to add more portfolio backlogs.
With custom backlog levels, you can add new portfolio backlog levels above Epics.
In the following image, we add a portfolio backlog called “Themes” above Epics, and associate the custom work item type “Theme” with this new backlog level.
![custom-backlogs-levels]()
Improved navigation for process customization
We’re updating the navigation involved in managing a process. The main change you’ll see is how you choose and modify a work item type. You’ll choose the work item type from a drop-down menu and modify it from the form layout. You no longer have to select the area you want to customize. From the form, you can perform all actions, including adding and editing of fields, modifying states, and later, maintaining the business rules.
![improved-navigation]()
Rules for work item types
With rules, you can set default values, clear entries, or restrict changes. With conditional rules, you can restrict to run a rule only on a specific state change, or when a field has a specific value.
When you define the rule, first you choose what needs to happen (action), and then when the rule needs to execute (condition).
![business-rules]()
Adding Identity fields
We currently support the most important field types such as text box, checkbox, and picklist. The number one request we’ve received is to also support custom identity fields, just like the Assigned To field.
Custom identity fields will render the same control as the Assigned To field, with the identity picker and avatar image.
![identity-field]()
REST API support for customization
Today we have a few APIs available to get a list of work item types, but we know you need more. If you are building on top of Team Services and TFS, you want to get the list of all processes in the collection and a list of all work item types in a process. You also want to know the fields and states of a work item type, including the state color. And you not only want to retrieve that data, you also want to update that configuration.
The next set of process REST APIs will deliver these capabilities to you.
Various process models
Dependent on whether you host TFS on your own servers (on-premises) or how your account was created in Team Services (cloud), you will be using one of these process models
- Inheritance
- Hosted XML
- On-premises XML
![process-model]()
Inheritance process model (Team Services)
All new accounts created in Team Services use the Inherited process model. The customizations and roadmap described in this post apply only to this process model.
To customize your project, you first create an inherited process from one of the system processes (Agile, CMMI or Scrum), and migrate the project to the new inherited process. A change to your inherited process immediately affects all team projects which use that process.
See our documentation to learn more about the customization of inherited processes
Hosted XML process model (Team Services)
At the Connect() event last November, we announced the migration from TFS to VSTS. Accounts imported from TFS to Team Services use this process model.
This model is very similar to the on-premises XML process model. The major difference is where the metadata for the team project is stored. Team projects which use the hosted XML process model, read their metadata from the process. A change to the process will affect all its team projects too.
To customize a process in this model, you download the process as a zip file, make the changes locally, and then upload the full process to apply these changes.
On-premises XML process model (TFS)
This process model is the traditional model used by all on-premises installations. As opposed to the other two process models, the metadata of a team project is not read from the process. When you create a team project, the process metadata is copied to the team project. As a result, any change to the process won’t affect the team projects. Instead you modify the metadata of the project using the command-line tool called witadmin.
Compare process models
The table below summarizes the differences between the various process models
| Team Services | TFS |
|---|
| Inheritance | Hosted XML | On-premises XML |
|---|
| Inherit system processes changes (Agile, Scrum, CMMI) | ✓ | | |
| Process changes affect team projects | ✓ | ✓ | |
| WYSIWYG editor | ✓ | | |
| Use witadmin to edit team projects | | | ✓ |
| REST API (read) | ✓ | ✓ | ✓ |
| REST API (write) | ✓ | | |
| Create custom processes | | ✓ | ✓ |
| Advanced customizations (global workflow, custom link types, global lists) | | | ✓ |
Future
We have received many requests to bring the Inheritance process model to on-premises. We are working through our plan for on-premises now, and expect to provide an update in the spring of 2017.
Keep the feedback coming!
Ewald Hofman
Yes, this is kind of a silly blog post but it's been bugging me for months so I wanted to get it out there in case it helps someone who is googling for the answer!
This extension adds one new Build & Release task, Yarn. With this task, you can execute Yarn in whichever project directory you need using configurable parameters. The wonderful reviews for this extension speak to the amount of time you potentially can save in your build process. The task is added under the “Utility” category.
