Mysterious Vanishing Work Items in VSTS

I’ve written about Microsoft’s Visual Studio Team Services (VSTS) in previous blog posts and it continues to provide enormous benefits to our project teams, particularly in managing work for Agile/SCRUM projects. I’ve served as a Scrum Master on many projects using VSTS and, despite all the benefits it provides, I do hear a common frustration from project team members, particularly those new to VSTS.

Typical statements I hear are…

  • “I entered that new user story we agreed upon and I saw it on our backlog board this morning when we added it, but now it’s gone!”
  • “Mary said she entered a couple of bugs for the user story I finished yesterday but I think she may have accidentally deleted the bugs because I don’t see them on our backlog board!”
  • “I’m not sure about this VSTS thing, it seems like things disappear and I’m not sure I’m confident in using it.”

When I hear these statements, I sometimes I feel a little like a high school teacher hearing a student say… “the dog ate my homework”!

VSTS is a very powerful system for managing complex product development work streams and it has some great tools like Kanban Boards to efficiently visualize that work. However, there are pitfalls that new users and administrators can fall into that create the types of frustrations mentioned above. With a system as comprehensive as VSTS, I’m sure there are many of these pitfalls. However, in this blog post, as a start, I’m going to mention the most common one I’ve noticed which is ”using default values for Iterations & Area Paths”.

I’m not going to describe what Iterations and Area Paths are in VSTS…I assume readers of this article already know that. I will simply say that it is very common on ThreeWill projects to use a single VSTS project to cover multiple releases of a software product or custom app and each release might have different iterations and/or area paths.

Figure 1 below shows the setup of a project with multiple iterations related to a custom app called “ProjectManagementTest”. In this example, the app has multiple releases (some major some minor) and those releases might be handled by different project teams.

\\.psf\AllFiles\var\folders\f3\g9wldzfj0nlfrvb8mkmfr4qc0000gn\T\2017-12-23_09-09-57 copy.png

Figure 1 – Iterations defined for ProjectManagementTest Project

It’s common for new requirements, i.e., product backlog items/user stories to be identified/uncovered as a project progresses. When a new user story/requirement is identified by one team, the actual implementation work for that user story might be handled in a separate Release by a separate project team.

Let’s say that I am working on a project team currently executing an Iteration called “Sprint 1” for “Release 1.0” in Figure 1 above. To make it easy for my team to enter these types of new user stories “on-the-fly”, I might use the VSTS “Default Team Settings” feature to automatically associate new backlog items to the top-level Iteration (called “ProjectManagementTest” in this example). With this approach, new/future requirements automatically get associated with, i.e., “parked”, in a top-level Iteration until release planning can be completed and the backlog item can be assigned to an agreed upon target release iteration. Sounds like a good idea – right?

But what if my team identifies a new requirement during iteration planning that needs to be included in our current iteration, i.e., “Sprint 1”? Let’s look at what happens in the Kanban Board for Sprint 1 in this situation. Let’s say that I add a new user story on the fly (see Figures 2 & 3).


Figure 2 – Adding a new Product Backlog Item (User Story) for Sprint 1


Figure 3 – New work item shows up on the Kanban Board as expected

However, when I refresh my browser page or navigate away from and back to the Kanban Board, I see Figure 4. What happened?!? My new user story is gone! It was just there. I know I saw it!


Figure 4 – Refreshed browser page is missing new Product Backlog Item

Where did my user story go you ask? Well…the Kanban Board in VSTS is a very powerful tool to filter/focus on work items. One of the filters that teams commonly use when viewing the Kanban Board is to filter by “@CurrentIteration” (see Figure 4).

When we first added the new user story, we did not specify an Iteration, so the value of the Iteration for that user story was set to “ProjectManagementTest” and not to “Sprint 1” which is what is displayed by the “@CurrentIteration” filter. However, the filter isn’t applied until the screen is refreshed. So, our new user story was displayed initially, but once we forced a screen refresh or navigated away from/back to the Kanban Board, it was removed from the Kanban Board display. Mystery solved.

How do I correct this mistake? Simple…you can remove the @CurrentIteration filter from the Kanban Board, then edit the newly added user story and change the Iteration to “Sprint 1” (see Figure 5 below).


Figure 5 – Iteration filter turned off to expose all backlog items

By the way…I mentioned “Area Paths” at the beginning of this blog post. A very similar scenario as mentioned above can occur if the default value for “Area Path” is set to a value that is filtered out by a team’s standard way of viewing backlogs or backlog boards. So, word to the wise, be careful about specifying default values when setting up your projects in VSTS.

I’m sure there are many other pitfalls that others have encountered and I may add more pitfalls in future blog posts. In the meantime, I’d love to hear from any readers about their experiences with VSTS pitfalls or even humorous things project team members say about those pitfalls!

Bob MorrisMysterious Vanishing Work Items in VSTS

Join the conversation

This site uses Akismet to reduce spam. Learn how your comment data is processed.