Shepherding User Requirements with TFS

Preview:

Citation preview

Shepherding User Requirements with TFSPatrick Tucker

KiZAN Technologies

About Me

▪ Practice Lead, KiZAN PREP Team (Process, Requirements, Experience & Planning)

▪ 17+ years as a developer, enterprise architect, trainer, speaker and business analyst

▪ Patrick.Tucker@KiZAN.com

▪ TuckersNet.AzureWebSites.net

▪ www.KiZAN.com

Summary

▪ Tools shouldn’t drive process, but the focus of this discussion is on how requirements live and travel through TFS

▪ We will look at gathering, grooming and protecting requirements using Visual Studio Online, the cloud version of TFS

▪ Our focus will be on Scrum and Agile, so we will be talking about functional and technical requirements related to those process templates

▪ Our focus will tend toward software development projects

Requirements Are Like Sheep

1.They must be gathered2.They must be guided and groomed3.They must be protected

They must be gathered…

Gathering Requirements

▪ What types of requirements do you gather?

▪ Where/How do you currently store requirements?

▪ How do you gather them?

▪ What tools help you gather requirements?

Types Business Functional

Where BRD Excel

How Interviews Wireframes

Tools Use cases User stories

End in Mind

Once we gather those sheep (uh . . . requirements), where are we going to put them?

Team Foundation

Server

Visual Studio Online

VS Online is FreeWeb based interfaceCan be opened in Visual Studio

What do you first think of when you hear TFS?

Creating the Project

TFS Template Options

Scrum

CMMI

Agile

Gathering and Adding Requirements

Requirement

Add Requirements, User Stories or Product Backlog items under features, depending on the template.

FEATURE

DemoCreating a Visual Studio Online project and choosing a template

The BacklogCreating a repository for requirements

The “Product Backlog”

▪ This is a backlog of all requirements

▪ May contain functional, non-functional, technical, and user interface requirements

▪ May be organized into features and work items

▪ What level of detail is best?

Zooming In

▪ 2 of 3 Cs – Card and Conversation (Confirmation comes later)

▪ Features (or Epics) create the framework around required areas of functionality

▪ User stories, requirements or PBIs gather initial detail

Requirements

▪ Requirements, User Stories or Backlog Items

▪ Can be mapped to Features

• Details• “As a business analyst, I can

write user stories so that developers can do work”

• Implementation• Tasks created by developers

• Attachments• Planning

• Story points, risk and ranking• Classification

• When do we do it?

Sheep Can Be Tagged

▪ Tags can be added as metadata to work items

Portfolio Backlogs

▪ If you need more than two levels of hierarchy for requirements, additional work item types can be created

Tools for Requirements Gathering

▪ You can use TFS/VSO and PowerPoint together to create storyboards

DemoBuilding a backlog of features and work items

They must be groomed…

Backlog Grooming

▪ Refinement after conversation; Adding detail and revising effort

▪ In Scrum parlance, Moving from “Product Backlog Item” to “Sprint Backlog Item”

Areas and Iterations

▪ Part of backlog grooming is deciding what is in or out of the current work

▪ Areas define projects (or manual sub-areas) and iterations define a set of work items to be addressed in a given time frame

▪ In an agile project, when should detail be added to user stories?

Gotta Find ‘em to Groom ‘em

▪ Queries can help to quickly and repeatedly locate items in the backlog

Prioritizing and Tracking

▪ A “Kanban” style board is provided

▪ Columns and workflow can be customized

Get a Room

▪ The conversation around requirements can happen in a TFS “room” when needed

▪ Manually added messages and automated event tracking

DemoEditing and reorganizing backlog items and using the “Board”

They must be protected…

Acceptance Criteria

▪ Scrum demands 100% definition of done

▪ Where does acceptance criteria (Confirmation - the 3rd “C”) go in TFS?

▪ Given/When/Then or A list of “shalls and shall nots”

Testing

▪ Multiple tests can be associated with each work item

▪ These can be acceptance criteria but also provide a series of steps to guide the developer, user or analyst testing the requirement

▪ Tests can be associated with “automation”

DemoAdd acceptance criteria and test cases

Requirements Are Like Sheep

1.They must be gatheredFeatures and User stories added to a backlog in TFS

2.They must be guided and groomedRequirements organized by area and path, presented on a board to show progress

3.They must be protectedConfirmation through acceptance criteria and testing

Questions?Patrick.Tucker@KiZAN.com

Recommended