States customization on Team Services
June 18, 2016
The first milestone in bringing states customization to Team Services is here. With the latest deployment, you can customize the states on your inherited work item types. Let’s jump into the new functionality.
Adding custom states
Adding new states starts from the process administration page. Here you can view all the states for a work item type, and add and modify them as needed.
To add a new state, simply click “New state” on the toolbar. Provide a name, state category (more on state categories later), and color for your state.
When typing a name in the dialog, the dropdown offers suggestions on states used by other work item types within the process. This allows process administrators to optionally standardize on the same states across work item types. This is purely a suggestion so you can choose to have different colors or state categories for the same state name if you wish.
Once you have added a custom state, the state will now appear in the states dropdown for the work item type as well as in the query editor. A couple things to note here: 1) you may have to do a full page refresh before you will see your new state and 2) the states currently appear in alphabetical order in the dropdown.
The color you specify will appear throughout the product including on the work item form, backlog, boards, query results, and more.
Removing custom states and hiding inherited states
In addition to adding custom states, you can remove custom states. To do this simply, open the context menu and click remove. Inherited states (denoted by the
icon to the left of the color) cannot be edited, but they can be hidden. You can learn more about process inheritance here: https://www.visualstudio.com/en-us/docs/work/process/manage-process
The impact of removing a state and hiding a state are equivalent:
- The state no longer appears in the states dropdown for that work item type nor does it appear in the query editor dropdown for the state field.
- New work items cannot move into the state.
- Existing work items maintain their state value, but are in an invalid state. If you want to make a change to the work item, the state values must be updated. If you add the state back to the work item type, these work items will become valid again.
- Work item history is left unchanged.
State categories
State categories are a new concept we are introducing. They are a named grouping for a set of states that allow experiences such as the backlog and board to work with customized states. The product currently supports five state categories:
- Proposed – These states represent work items that are not yet being worked on and will appear on the backlog. The first column on the Kanban or Task board must map to a Proposed state.
- In Progress – These states represent active work. These states will appear on the backlog, and make up the middle columns of your Kanban board.
- Resolved – These states represent work items that have a solution, but are not yet verified. Generally applicable to bug work item types. Work items in a Resolved state will now appear on the backlog by default.
- Completed – The Completed state category represents finished work items. You cannot modify states in this category nor can you add states to this category at this time.
- Removed – Work items in a state that is mapped to the Removed category are hidden from the backlog and board experiences.
Still to come
In this initial release, we focused on enabling the most common scenarios of adding custom states. There are still a few more we have on our backlog that we will pick up later in the year:
- Ordering – We want to make order a first class property of states and have the states dropdown reflect this. This will enable users to reorder states within a state category.
- By/Date fields – One of the top customizations customers do today with states is to write rules that track who performed a state transition as well as when the transition was performed. We want to make this a first class part of custom states by enabling this automatically.
- Transition restrictions – We’ve seen many enterprises have specific workflows that enforce certain state transitions (e.g. the work item must be Resolved before it can be Closed) as well as business logic on transitions (e.g. only the PO can make a work item Active)
Please comment or email with any feedback or questions.
Derrick Fu
Progam Manager, VSTS
You forgot to mention the most important new feature:
YOU CAN NOW FINALLY HAVE CUSTOM COLUMNS ON THE TASK BOARD!!!
Thank you!
Question: We want to rename the columns on the task board from “New, Active, Resolve, Closed” to “Planned, In Progress, Test, Done”. Do you have plans for renaming the display name of “Inherited states”, or should we create custom states in the respective “State categories” and hide the “Inherited states”? Are there any drawback if we do that?
It’s strange that you don’t have the option to rename display name, because you are able to do just that in different processes (Scrum, Agile, CMMI). And we are not just talking state… but all/most fields in VSTS. E.g. it’s not “Iteration” it’s “Sprint”, it’s not “Feature” it’s “Epic”, it’s not “Value Area” it’s “Story type” etc. (Naming is everything).
That said… oh boy… VSTS is fast becoming the best software process tool I’ve ever used 🙂 Keep rocking.
On “small” feature request: An icon/shortcut to collapse all stories on the Task board. On our daily (remote) stand up the first thing we do is to collapse all stories to get an overview of the sprint, and because we don’t have instant update like on the Kanban board (hint hint) we often need to refresh to see team members updates, and then collapse all stories again.
And maybe one more: A way to high light all stories/tasks/bug that has been change since last stand up would be really cool.
And then bug report: The burn-down chart for a e.g. 2 week sprint (10 working days) only show 9 columns (first day missing). That means that first day can’t be tracked, and the burn-down is “optimistic”, where it should be “pessimistic”. Also when we were evaluating VSTS we though we were doing something wrong, because we didn’t know we had to wait a day, to see progress.
Thanks for your feedback, Thomas. Glad to hear you are liking the new features 🙂
We are planning to bring a lot of the column customizations available on the Kanban board to the Task board. This is still in the planning stages so I can’t offer you an ETA at this point. As for renaming inherited states, our guidance is to create a custom state and hide the inherited state. The only drawback is you will have to manually update any existing work items in the state you hid, which can be done via querying and bulk editing.
I’ve relayed your task board feature requests to the feature owner. For seeing all work items changed since the last stand up, setting a styling rule that colors cards with “Changed Date > @Today – 1” could be a suitable solution for now.
The burndown chart is limited by only tracking day to day data points. This means we to capture all the work to midnight of the last day of the sprint exactly, we must have the initial data point start the second day of the sprint. I understand this isn’t ideal. I’ll make sure to pass your feedback along to the right people.
It is very well feature!!!
How can I map my custom states to the column in my Kanban board? I don’t see my new state as an option for selection when configuration my Kanban board columns. Specifically, we’ve had a Ready for Test and Testing board columns for awhile, and I would like to back this up with a State to accompany it, so that we can report on state for a cleaner view in dashboards.
How can I map my “Testing” board column to my custom state “Testing” ?
Hi Kaitlyn – your custom states should appear as options in your Kanban board mapping experience. Custom states need to be in the “In Progress” or “Resolved” state categories to be mapped to the active columns on the board (i.e. middle columns).
Hi Derrick
I have opened my project to look at playing with this feature.
Unfortunately the state breakdown does not display any label names or state category. I have the functions available to view and can create a new state within a category which is then selectable but as I say the structure label names do not appear. Is anyone else experiencing this or is there some feature that requires enabling. Any guidance would be appreciated.
Regards
Ian
Hi Ian – can you tell me more about what you mean by label names? The state category is not a concept we expose directly in our Agile and work item tracking experiences. It is simply an attribute of the state that allows experiences to work with custom states.
Hi Derrick
So if you take the screen shot at the top of this page under Adding Custom States I have a number of rows which have the function icon but no label names are displayed like under Proposed (New & OnDeck) etc. If it would help I could mail you a screen shot of what I am seeing.
Regards
Ian
Hi Derrick
I have sussed it. I have mainly been working using Chrome as my browser, if I switch to view in IE, labels appear as above so its a browser issue just for this feature. All other functions are ok.
Regards
Ian
Thanks, Ian. Please send me a mail with a screenshot of the issue in chrome: derfu@microsoft.com
This is great work!
For Kanban teams, there’s a lot of emphasis on Board Columns often instead of States, however there’s some key gaps, here’s a few.
Board Columns don’t show in the work item form by default, States do. You can add Board Column and Board Column Done to the form, but it’s located separately from State, and you can’t obscure State.
When creating charts on the dashboards that display Board Column, there’s no way to universally indicate that a specific Board Column is a certain color, which means you have to do it for every chart that is created, but you can only do it once the state appears on that chart.
Board Column Done when displayed is true/false, would would be a better experience is to display something like Doing/Done. Maybe Board Column and Board Column Done could be a combined output when needed, e.g. QA Testing: Doing and QA Testing: Done.
Querying for Board Column and Board Column Done data and transition information like person who made the change, date and time of change, etc. to generate things like Cycle Time or more informative CFD’s isn’t nearly as easy as querying for States.
On the topic of CFD, the current one isn’t as useful as it could be, partly because of the monochrome pallette (blue, lighter blue, even lighter blue, even lighter than even lighter blue blue, etc. Comment above about colors for charts for Board Columns would be great if they could be applied to the CFD as well. Also making it a little easier to extract WIP and Cycle Time from the CFD would be hugely valuable, it’s very hard to gauge right now.
Hi Mac,
Thanks for the very detailed feedback. As you described, there is a lot of “power” in states (e.g. querying, charting) that is not present in Board Columns. This is, in some respects, by design. We want to enable organizations to drive alignment across teams via states customization while still giving teams the flexibility to be autonomous via board columns that map to the states. In doing this, there are going to be tradeoffs in using states v. board columns that you accurately called out.
That said, we can definitely improve some of the usability around board columns and your reply will help us decide where to focus our efforts.
I have followed these steps for an agile process that we have but the user story states I added don’t actually show up when I click on a user story. Is there something I am missing when adding a state to a user story?
Hi Chad,
Are you sure the process you edited maps to the project you checked for the new state? What state category did you add your custom state to?
Hi Derrick
I’m looking forward to the transition restrictions. Is there a “public” release date defined?
Moreover I’ve been told that there’s a preview available on some accounts, so is it something that we could get as well? I’d be happy to test the implementation of this functionality.
Hi Adrien,
We’re in the process of finalizing our planning for the next set of customization features. Transition restrictions is definitely on the list. Unfortunately, I don’t have any release dates to give at this point. You can expect we’ll do a blog post update when we have more clarity here.
As to the preview, you can learn more about that here: https://blogs.msdn.microsoft.com/visualstudioalm/2015/08/12/visual-studio-online-process-customization-private-preview-or-vnext/
Is there any way to query using state categories via wiql and API calls? I would like to be able to retrieve all items in a state classified as “In Progress” regardless of what the states name is or which process template is being used just based on the state metadata.
Hi – we are currently working on a set of APIs that will expose the state category per work item type. Enabling querying on state categories via WIQL is on our backlog, but there is no ETA at this time.
Thanks for the article, I went through this when standardizing states across Bugs and Tasks for my team.
There is one issue though. Because of a lack of ordering of states, my Swimlane states in the Backlog board view do not appear in the correct order. Ideally a left to right approach would be best, for ex: In Planning, New, Approved, In Progress, In Test, Done
Is there a way to reorder the Swimlanes columns ?
Many Thanks
Shailen
Hi Derrick
We have two definitions of done (=DOD).
One is the DOD for the sprint and one is the DOD for the release. This is because currently we cannot do all the tasks needed for a workitem to be released in one sprint.
So our current solution is to have a custom state called ‘Sprint DONE’ within the state categorie ‘In Progress’.
So now I am wondering if you can let a workitem automaticaly collapse on the taskboard with another state then by the ‘Closed’ state (Completed state)?
Sorry Charlotte, but the task board doesn’t have the ability to automatically collapse the row when it is in the In Progress state. It is hard coded to the Completed state category only.
Another approach is to use the Features to track all the work you want to release. Features can span multiple sprints. Then you have breakdown the feature into story or PBI that span only a single sprint. Would that work?