VSTS for the Lone Wolf Developer – Work Item Management

The work item functionality may seem a bit complicated if you’re not familiar with TFS or Agile. Let me show you how to use it for simple projects, as well bigger ones, in Visual Studio Team Services (VSTS).

Work Item Management

When I started my side project I knew what I was building. It was all in my head. Over time I :

  • kept coming up with ideas for future development
  • needed to prioritize and phase in features
  • had a constant list of small items to-do items, which I had to come back to

All this information needed a home.

When I first looked at the Work item area it didn’t make sense. A while later I went on an Agile course and everything made sense.

How I would use Work Items for a small project (aka using it like Trello)

If you have a smaller project or want to keep things really simple, I suggest you do this:

  • Go into Work > Backlogs > Stories. Make sure you click the Backlog link.
  • Once there, create some basic Stories
    • At a minimum, enter a name
    • If needed, open it up and enter more detail in the description field
VSTS backlog
Stories backlog
  • If you’re working on an item, click on Board and drag the item from the New column to the Active column.
    • Pro tip: don’t have too many items under Active at any one-time. You’ll notice, under Agile, you’re limited to 5. You can change that
VSTS stores board.png
Stories board
  • From the backlog, drag-and-drop the items so they’re in a priority that makes sense
  • Once you’re done, put it under Closed

You can add/remove/edit the columns by clicking the little gear icon. See this article for more info. You can also create horizontal swimlanes.

If you’re new to this, I would suggest you leave it as-is and customize it later, once you’re more familiar with it.

How I would use Work Items for a larger project

Epics, Features, Stories, Tasks

We want to create a logical hierarchy of tasks, similar to this picture.

Example of the hierarchy from the VSTS site

I treat these as very high-level goals. I only have a a few. With our Wolf Tracking app we could have Epics for:

  • Xamarin mobile App
  • Angular admin app
  • Reporting

You can click Epics, select Backlog and quickly enter them. I usually don’t bother with anything other than a name.


These are children to Epics and describe the high level features you want to build. Don’t be too specific at this point.

For example: assuming an Epic of “Mobile App” a feature could be the Login page.

I keep the features pretty simple. I usually only enter a title.

You can add Features easily from the Epics backlog or board. Notice the green + sign. The advantage of doing it here is it automatically links the feature to the Epic.

VSTS Epic backlog
Epic with features, under the Backlog view
VSTS Epics board
Epic with features under the Board view
User Stories

A user story explains what the user expects from the feature. It’s told from the user’s point of view.  In my opinion, that is something we devs can lose sight of.

Recall the feature “Recording of Wolf Information”? Let’s add some user stories. Notice I’m still under the Epic tab. I could have gone to the Features tab and added them there or have gone into Stories, entered them there and manually linked them back to the Epic.

VSTS epic with features and stories.png
We have some user stories under the Feature

In my opinion there are three key things to do when you create a user story:

  1. Give it a meaningful title
  2. In the description enter the user story. I suggest you use the story method of “As … I want to… so that…”. Checkout the example below or have a read of this.
  3. Enter acceptance criteria. Enter at least one and use the method “Given a… when… then…” seen in the example below or in this article.
    • This method of writing acceptance criteria is a really nice way of describing how it should work. It’s practically a test plan
    • You can create multiple acceptance criteria (i.e. scenarios when it should work, when it shouldn’t, etc)
    • This info is essentially what you need to write functional tests with SpecFlow, Cucumber, etc
  4. Optional: use the Personas add-on and add their name as a tag. It’s a great way of remembering who will use it

VSTS user story

By the way, here’s the example Persona. You need to install the Persona add-on in order to do this. I was able to see the Jane persona by clicking her image in my user story.

VSTS persona example
Jane’s persona. Click to see a bigger version

In the user story you can use the Planning and Classification section if you want to. Personally, I don’t bother.


Tasks are very important. Without tasks the iteration functionality may not make much sense / be of much benefit.

It’s up to you when you enter tasks. The tasks are the specific to-do items – for you – to implement that story.

As a lone wolf I tend to write the tasks just before I start the work or at the start of an iteration. They’re useful to remind me of where I’m up to, document bits and pieces I need to come back to and are great motivation (I love marking things as closed).

Note that, for a task, I usually don’t enter anything more than a title.

VSTS Epic with tasks.png

We now have Tasks against a feature

Iterations – where it all comes together

The purpose of the iteration is to decide what user stories you will tackle within a period of time (i.e. 2 weeks). Iterations are also known Sprints.

As a lone wolf, you don’t want to take on too much at one. Decide on a small slice of functionality, get it built and into the hands of your users. Then move on.

You will have an iteration waiting for you to use (Iteration 1). You can assign the user story to the iteration by:

  • Opening the story then setting the iteration or
  • Right clicking the story, select Move to Iteration and selecting the iteration
VSTS iteration 1
Our first iteration!

If you click over to the Board you will see the tasks in a board. You can drag and drop the items between the columns.

The end goal is to have all the tasks marked as closed and the state of the user story set to Complete.

VSTS iteration 1 board.png
The task in board view. Notice how you can drag and drop items between columns and add more tasks

What about Bugs?

Bugs are entered under a user story, like tasks. The one key difference is that bugs can only be entered if the user story is in an iteration.

We’ll talk about bugs in more detail, in the Stakeholders and Testing section.

VSTS bug example
Example of a bug entered by hand. Note that bugs MUST be under a user story which is part of a iteration

Closing Iterations, Creating new ones

Let’s say you finish the current iteration and want to create a new one. This is where it’s not so obvious.

On the top blue menu bar hover over the gear icon then select Work. From here you can edit an existing iteration, create a new one, etc. You can also give the iteration a more meaningful name.

VSTS iteration definition.png
To edit the iterations click the Gear icon, then select Work


Next: Stakeholders and Testing

Previous: Source Control and Extensions

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: