Understanding how TFS/Visual Studio Online can be leverage as a tool for gathering, grooming and validating requirements.

1. Shepherding User Requirements withTFS
PatrickTucker
KiZANTechnologies

2. About Me
▪ Practice Lead, KiZAN PREPTeam (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

3. Summary
▪ Tools shouldn’t drive process, but the focus of this discussion is on how requirements
live and travel throughTFS
▪ We will look at gathering, grooming and protecting requirements usingVisual Studio
Online, the cloud version ofTFS
▪ 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

4. Requirements Are Like Sheep
1.They must be gathered
2.They must be guided and groomed
3.They must be protected

5. They must be
gathered…

6. 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

7. 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 Free
Web based interface
Can be opened inVisual Studio
What do you first think of when you hearTFS?

8. Creating the Project

9. TFSTemplate Options
Scrum
CMMI
Agile

10. Gathering and Adding Requirements
Requirement
Add Requirements, User Stories or Product Backlog items under features, depending on the template.
FEATURE

11. Demo
Creating aVisual Studio Online project and choosing a template

12. The Backlog
Creating a repository for requirements

13. 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?

14. 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

15. 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?

16. Sheep Can BeTagged
▪ Tags can be added as metadata to work items

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

18. Tools for Requirements Gathering
▪ You can useTFS/VSO and PowerPoint together to create storyboards

19. Demo
Building a backlog of features and work items

20. They must be
groomed…

21. Backlog Grooming
▪ Refinement after conversation; Adding detail and revising effort
▪ In Scrum parlance, Moving from “Product Backlog Item” to “Sprint Backlog Item”

22. 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?

23. Gotta Find ‘em to Groom ‘em
▪ Queries can help to quickly and repeatedly locate items in the backlog

24. Prioritizing andTracking
▪ A “Kanban” style board is
provided
▪ Columns and workflow can
be customized

25. Get a Room
▪ The conversation around requirements can happen in aTFS “room” when needed
▪ Manually added messages and automated event tracking

26. Demo
Editing and reorganizing backlog items and using the “Board”

27. They must be
protected…

28. Acceptance Criteria
▪ Scrum demands 100% definition of done
▪ Where does acceptance criteria (Confirmation - the 3rd “C”) go inTFS?
▪ Given/When/Then or A list of “shalls and shall nots”

29. 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”

30. Demo
Add acceptance criteria and test cases

31. Requirements Are Like Sheep
1.They must be gathered
Features and User stories added to a backlog inTFS
2.They must be guided and groomed
Requirements organized by area and path, presented on a
board to show progress
3.They must be protected
Confirmation through acceptance criteria and testing

32. Questions?
Patrick.Tucker@KiZAN.com