Last month we unveiled a new section of our features timeline that highlights items we're actively working on. As Brian described on his blog, we're laying out a rough timeline of when we expect new functionality to be available on VS Online as well as TFS on-premises. This morning we updated the timeline with a bit more detail about some investments in the agile project management space. The list is not comprehensive – there are things we’re doing that are not included here – but I wanted to take the opportunity to walk through some of those investments in a bit more detail.
Note: In all the descriptions below I’m using concept art rather than actual screenshots of the product. Don’t worry, we’ll make it look good. :)
Kanban – Add & Reorder
We’re actively working on changing the Kanban board to allow adding and reordering directly from the board. Many of you have told us that you want to work on the boards exclusively, and only leverage the backlog view when necessary. This change is a step in that direction. Adding will always happen in the first column, while reorder will be available on all columns.
In the picture below, notice that I have an add command in the New column. When clicked, a new card is added to the first position in the New column where you can inline add the title of the new story, feature, etc.
Reordering is simple. Using the same picture, let’s imagine you want to move item #987 up in priority. Just grab the item, move it to the correct position, and you’re done.
Changes made on the Kanban board are reflected directly on the product backlog as well. Both add and re-order are coming in Q1 of this year.
Kanban – Split Columns
Most Kanban teams use a pull model to move work through their board. To do this effectively, each column on your board is “split” into two sub-columns – Doing and Done. This provides a clear signal that work is ready to progress, and can be pulled by the person/team/etc. who owns that next stage.
Let’s take a look at what a board looks like today without split columns. Notice the “In Dev” column has three items, but there’s no way to indicate if one of these items is done and ready to be pulled into the “In Test” column.
Here’s a picture of that same board but with the “In Dev” column split into a “Doing” and ”Done” sub-column. The team can now indicate on the board that item #987 is done and is ready to be pulled to “In Test”.
Split columns will be coming in Q1 of this year.
Bugs on the Taskboard
Teams use different approaches when working with bugs/defects. We want our tools to support these approaches without mandating "one size fits all'". Flexibility here is really important. The three approaches we’ve identified are listed below. In each picture, blue cards are Product Backlog Items (PBIs) or User Stories (depending on your process configuration), yellow items are Tasks, and red items are Bugs.
Approach 1 - Decomposing Bugs as you would decompose a Product Backlog Item (PBI). This is the approach Scrum advises. Bugs show up on your Product Backlog and are planned, decomposed (using Tasks) and completed during a sprint, just like any other item on your backlog.
We enabled the ability to work this way (regardless of process template) late last year. You can read about this configuration in our release notes published on November 4.
Approach 2 - Visualizing Bugs as you would visualize Tasks. In this approach, Bugs are typically parented to items on your backlog and managed just like Tasks. On the Taskboard, Bugs show up alongside Tasks or in their own swim lane if they are not parented to an item from your backlog.
This configuration is the next one we’re turning on. Our plan is to have this ready for you to use on Visual Studio Online by the end of Q1 of this year.
Approach 3 - Bugs are given their own board separate from the Taskboard. With this approach, bugs do not show up on your product backlog but are given their own board alongside your Taskboard when they are assigned to a sprint.
Supporting this scenario will come after we’ve wrapped up the scenarios above. We’re shooting for Q2 of this year.
Kanban – Definition of Done
For each column on the Kanban board we’re adding the ability to add a text description for you to describe what “done” means for each column. The text will be displayed on hover over an information icon that will be added to column header.
Definition of done is coming in Q2 of this year.
Hierarchical Backlog Reordering and Re-parenting
We’ve known for some time that our hierarchical backlog views lack a lot of functionality. They’re great for analyzing and tracking relationships, but lack interactivity. For example, today you can only re-order and re-parent items when looking at a flat backlog. This is often limiting because viewing and editing the backlog in context of the hierarchy is a more natural way to work.
We’re fixing this by making changes to enable you reorder and re-parent items in any view on the backlog. In the example below, let’s imagine you want to take Story D and re-parent to Feature 1. Just click on Story D, drag it up to Feature 1, and place it in the exact position relative to other children of Feature 1.
The result would look something like this. From here, if you wanted to reorder within Feature 1, you could do so by dragging and dropping items into the correct position.
We made a similar change to the sprint based views late last year. This change will be delivered in Q2 of this year.
Kanban - Swim Lanes
On all Kanban boards we’re introducing the ability to create a new horizontal lane for work that needs to be treated differently from your normal flow. Many people refer to this as an expedite lane because it’s used for emergency work that can skip queues and preempt other work.
Below you can see that item #987 has been pulled into a separate horizontal lane so that the team can visually differentiate it from other work.
Swim lanes will be coming in Q2 of this year.
Kanban – Lead Time
A critical metric to teams practicing Kanban is the idea of lead time. Lead time is measured as the amount of time between work starting and an item being delivered. The clock starts as soon as the work starts, and the clock stops when the item is “done done”. The picture below shows how to think about lead time in light of the basic Kanban board we started with above.
In this example, item #123 does not yet have lead time. Why? Because it’s still in the “New” column. Work has not yet started. Item #321 however, is in the “Design column”. As soon as it was dropped into “New” column, the clock started ticking on lead time.
We’re working on ways to allow you to configure and monitor lead time and other Kanban metrics. This capability (lead time) will be available by the end of Q2 of this calendar year.
Kanban/Taskboard – Card Customizations
Today, cards on your Kanban boards and Taskboards are more or less hard-coded. Each card has a title, the user assigned, and a value representing effort. While these basics are useful, it’s limiting to not be able to change this data or add additional information. Over the course of Q1 and Q2 of this year you will see us start to unlock this capability. This will include adding additional fields, displaying tags, and inline editing information directly on the card.
I hope you’re excited about these changes, and as always, don’t hesitate to reach out with feedback, thoughts, questions, etc.
Thanks, Aaron