Setting up Requirements in VSTS

This article is republished from my original Setting up Requirements in VSTS post on fantail.io.

Last week I started a new project with VSTS, setting up some Git repos for my code.  Now it's time to set up some requirements and planning for the development.  I chose to set up an Agile project last week, which is one of 3 default project types in VSTS.  This affects a number of things, including the form the requirements take and the development process used.  Agile is the most flexible, and is the one that I use most often.  Requirements are added to a project as Work Items:

Most of my requirements will take the form of User stories, a common Agile construct.  These stories express a requirement in terms of a Persona, performing some Action to achieve a Result.  When you use this format you tend to drill down on the requirement, writing it in a format that's easy to understand and to develop.  Features are a piece of functionality that you want to deliver, and can be used to group stories together, while an Epic is a large, long running objective composed of many Features and User Stories.

The Work menu in VSTS is where you go for requirements and work tracking.  When you go to Work, it has some iterations set up by default and is ready for you to start adding your stories.  I'm going to set up some things first, to match how I want to work.

The Cog or Gear wheel (⚙) leads you to the settings in VSTS - but there are 2 on this page.  The one in the main menu covers settings for the overall project while the Gear icon on the stories table controls settings for the Backlog view.  Click this, and select Backlogs on the popup.  I am going to turn on Epics here, so they can be managed on the backlog.  When you save this, you'll return to the product backlog with Epics, Features and User Stories available down the side. 

My project is a travel agency system, something used for booking travel and accomodation around the world.  I have found some data sources online covering Airports, Routes and Airlines and I will start here, adding in more services and data stores as I go.  Time start adding some Features and User Stories! 

At this stage we're working with a product backlog, or a grouping of requirements that need to be done to deliver functionality but aren't yet in a sprint.  VSTS has 2 different types of backlogs, for Products and for Sprints.  Click on Epics, Features or User Stories to see the product-level backlog, or one of the Iterations to see a sprint backlog.  I selected the Features link, and can start adding features easily by typing in the title then pressing add.

As I said, first off I'll be working on Airports, Routes and Airlines so I will add features in this area.  I need Create, Read, Update and Delete operations for these domain objects for starters, and a couple of other domain objects that will come in useful.  These will be my first features:

• Maintain Airports
• Find / Search for Airports
• Maintain Routes
• Find / Search for Routes
• Maintain Airlines
• Find / Search for Airlines
• List Country Data
• Maintain Cities
• Find / Search for Cities

These aren't very exciting features, are they?  I am going to create an Epic covering this reference data, then map the Features to the Epic.  You can do this by clicking the Mapping button to turn it on, then dragging and dropping the Features onto the Epic.

Fortunately you can multi-select by holding down Shift, Control or Command (Mac).  Next, click on the + button beside a Feature (see Maintain Airports above) and add your User Stories.  For Maintain Airports I'll add the following:

In my system, only Admin users should be able to update this reference data - but when it comes to finding airports I add the following stories:

• As a Travel Agent I want to Find Airports by City so I can Suggest Flights
• As a Travel Agent I want to Find Airports by Country so I can Suggest Flights
• As a Customer I want to Get Airports so I can See Information About My Flight

These are all expressed in "as a Persona I want to Action so I can Result" format, which helps by clearly laying out who you are and what you want to do, but most importantly what you want to achieve.  This helps us by identifying actors and roles in your system (Admin, Travel Agent, Customer), which can hint at security roles in future as well user types that have to be considered in other stories.  It lists the capabilities we are building, as the actions will be methods or functionality we will code in future.  Finally it gives what the user is trying to achieve, which helps when the story is ready for development, as it sets the context for the action and helps set the functionality being delivered within the wider application.

I am going to add the rest of the user stories now, next post I will set out acceptance criteria for the stories and break down some tasks.

Adam Knight is an Auckland-based Senior Solution Architect in Equinox IT's Cloud business.