Accessing VSTS

Follow the below steps to access VSTS and to locate the Organization and Project space the Product Backlog Items (PBIs), Features, and Epics will be documented within:

1. Access VSTS
2. Select the Organization and Project you will be working on
3. From here there are multiple ways to navigate to the Board you will be working in. One path is as below:
   1. On the left-hand menu select Boards and then Backlogs. This will take you to project backlogs within your organization.
   2. Use the dropdown shown below to change projects as necessary.

Creating an Epic

To create an Epic, follow the below steps:

1. Select New Work Item from the top row navigation and enter the Epic Title you wish to use.
2. You can choose to add the new Epic to the top, bottom or at the selection your cursor was previously on of the backlog
3. Locate your new Epic and click on the Title to open. Here you will add details of the entire Epic that is being created. This should encompass what each Feature and PBI within the Epic will cover but from a very high level and basic explanation.
4. Verify the Area and Iteration are accurate
5. Add a Description using the below format:
   • For: (business unit or role)
   • Who: (what they do that is being created/changed/enhanced)
   • The: (name of system where creation/change/enhancement is taking place)
   • Is: (what the solution will do)
   • That: (what the change/enhancement will do)
   • Unlike: (current problem/missing functionality)
   • Our solution: (benefit)
   • Out of Scope: (list anything out of scope for the initiative) *optional
6. Add Acceptance Criteria (AC) using the below format:
   • I know this Epic is complete when:
     • AC1: (brief description of one Feature)
     • AC2 and on: (brief description of each additional Feature using one AC per Feature)
7. Complete the Budget Type, Capitalizable, Department and Run and Grow fields
8. Add the Start Date, Target Date, Priority, Effort, Business Value and Value Area as soon as they are known.

•  

Creating a Feature

There are multiple ways to create a Feature:

1. Within an Epic, on the right-hand side click the drop down by Add Link and select New Item
   • The Link Type should be Child and the Work Item Type will be Feature
   • Enter the Title you wish to use for the Feature and click OK
2. When viewing the Backlog Epics, locate the Epic you wish to create a new Feature for and click on the + to the left of the Epic
3. Enter the required information and save

Feature details should be as follows:

5. Title
   • Confirm you are using the agreed-upon naming convention particularly when there are multiple Epics within a project that contain Features
6. Verify the Area and Iteration are accurate
7. Add a Description using the below format:
   • As a: (user title or role)
   • I want: (the user description of what is being created/changed/enhanced)
   • So that: (the gain the user is receiving due to what is being created/changed/enhanced)
   • Out of Scope: (list anything out of scope for the initiative) *optional
8. Add Acceptance Criteria (AC) using the below format:
   • I know this Feature is complete when:
     • AC1: (brief description of one PBI within the Feature)
     • AC2 and on: (brief description of each additional PBI using one AC per PBI)
9. Complete the Budget Type, Capitalizable, Department and Run and Grow fields
10. Add the Start Date, Target Date, Priority, and Value Area as soon as they are known.

Creating a PBI

1. There are multiple ways to create a PBI (Product Backlog Item):
2. Within a Feature, on the right-hand side click the drop down by Add Link and select New Item
   • The Link Type should be Child and the Work Item Type will be Product Backlog Item
   • Enter the Title you wish to use for the PBI and click OK
3. When viewing the Backlog Features, locate the Feature you wish to create a new PBI for and click on the + to the left of the Feature
   • Enter the required information and save

4. PBI details should be as follows:
   • Title
     1. Confirm you are using the agreed-upon naming convention

5. Verify the Area and Iteration are accurate
6. Add a Description using the below format:
   • As a: (user title or role)
   • I want: (the user description of what is being created/changed/enhanced)
   • So that: (the gain the user is receiving due to what is being created/changed/enhanced)
7. Add Acceptance Criteria (AC) using the below format:
   • AC1:
     1. Given (statement of what precedes the action a user will take)
     2. When (the action the user is taking/what is considered the user test of the functionality)

• • Then (the result of the action the user takes/what result would be considered passing of the user test)

• • AC2 and on: (follow same format above, creating an AC for each user testable functionality of the PBI)

8. Complete the Budget Type, Capitalizable, Department and Run and Grow fields
9. Add the Priority, Stack Rank, and Value Area as soon as they are known
10. Add the Effort through grooming activities.

 

Creating a Production Incident or Bug

There are multiple ways to create a Production Incident or Bug:

1. Within a Feature, on the right-hand side click the drop down by Add Link and select New Item
   1. The Link Type should be Child and the Work Item Type will be Production Incident or Bug
   2. Enter the Title you wish to use and click OK
2. When viewing the Backlog or Sprint Features or PBIs, locate the Feature or PBI you wish to create a new Production Incident or Bug for and click on the + to the left of the item
   1. Enter the required information and save

Production Incident details should be as follows:

1. Title
   1. Confirm you are using the agreed-upon naming convention
2. Verify the Area and Iteration are accurate
3. Add Repro Steps outlining the details of the incident identified including:
   • Expected behavior
   • Points of failure
   • Impacted volume if known
   • Any other relevant details to help troubleshoot
4. Add Acceptance Criteria (AC) using the below format:
   • AC1:
     1. Given (statement of what precedes the action a user will take)
     2. When (the action the user is taking/what is considered the user test of the functionality)
   • Then (the result of the action the user takes/what result would be considered passing of the user test)
   • AC2 and on: (follow same format above, creating an AC for each user testable functionality of the incident)
5. Add the Priority, Root Cause, and Severity as soon as they are known
6. Add the Effort through grooming activities

 

Following a work item

Within VSTS there is an option to follow work items. This will trigger notifications to be emailed to you any time there is a change to the work item.

1. On the right side of any work item, flick on the Follow button. It will change to Following once it is activated and remain so until un-followed by clicking again.

 

Adding attachments

Work items in VSTS have the ability to store attachments.

1. Click on the tab with the paperclip icon and either drag and drop or browse and upload any relevant attachments.

 

Reviewing historical changes

VSTS tracks changes to all work items. Click on the icon that is a clock with counter-clockwise arrow around it. In the History section, select the item you want to review and details of the changes made will show in the window on the right.

 

Viewing Linked or Related Work

VSTS shows Linked, otherwise known as Related Work, in two areas. The first is within the Linked tab. The second is within the Details tab, under Related Work on the right side:

 

General rules for Links/Related Work

The below outlines general rules for Related Work within VSTS:

• A Parent is an over-arching umbrella to help track work to the appropriate process and team
  • Every PBI requires a Parent Feature
  • Every Feature requires a Parent Epic
  • Epics do not have Parents
  • Production Incidents and Bugs may have a PBI, Feature, or Epic as a Parent, as long as one is selected
• Predecessor (to be done prior), Successor (to be done after), and Related (to be done with) links help to manage completion order of work and are optional

 

Best Practices to follow for a PBI

As Product Owners there are multiple ways to create and manage PBIs. Some helpful ‘best practices’ are outlined below for reference.

• Create PBIs using user language, otherwise known as “User Stories”.
  • This will tie back to any requirement documents you are maintaining and will help to achieve the actual business purpose of the functionality being built.
  • It should be written in such a way that should you present it to the business you are partnering with there will not be any confusion as to the development that is requested.
  • It keeps the PBI testable by both your testing and business partners because it is clear how the functionality represents an action within the business process
• Use And/Or qualifiers as needed within the PBI and the AC to elaborate on dependencies within the requested functionality
  • Example: As a business user I want to be able initiate a new case AND be required to enter a name, description, and due date so that my work is assigned case numbers and stored in the system of record
• Make each AC a clear and testable item that specifically relates to the description of the PBI
  • When necessary, use positive/negative tests, for example:
    • AC1: Given I am a business user when I initiate a new case and I enter the required information then the system WILL create the new case and assign it a case number
    • AC2: Given I am a business user When I initiate a new case And I DO NOT enter the required information then the system WILL NOT create the new case and assign it a case number
  • Make each PBI consumable depending on the sizing system used by your organization.
    • PBIs should be completable within a single Sprint
    • It is better to split a PBI into multiples than to miss Sprint completion and negatively impact team velocity
  • Complete your PBIs to their fullest possible extent prior to presenting them to Development/Technical partners to avoid lengthy grooming and multiple back and forth clarification needs.
    • Obtaining business approval on the requirements and teaming up with your project partners (peers, Product/Project Managers, etc) to do an initial review or pre-grooming may help accomplish this goal
  • Encourage your Development/Technical partners to leave PBIs as “User Stories” and to create linked Tasks or “Technical Stories” as necessary to avoid altering the business requirement.