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
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?
10. Gathering and Adding Requirements
Requirement
Add Requirements, User Stories or Product Backlog items under features, depending on the template.
FEATURE
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?
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
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”
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