This document provides an overview of implementing Scrum using Microsoft Team Foundation Service (TFS). It begins with introductions of the presenters and an agenda. It then covers TFS overviews and comparisons of editions. It discusses setting up code in TFS and Git source control. There is an overview of Scrum principles and processes. Finally, it details activities for Sprint 0 planning such as defining the product backlog, sizing and prioritizing items, and demoing these features in TFS.

1. Day I
Implementing Scrum with
Microsoft Team
Foundation Service (TFS)

2. Ben
Hoelting
In truth, he’s just a big kid. He loves designing
systems that solve real world problems. There is
nothing more satisfying than seeing something you
helped develop being used by the end users. Ben is
also involved in the technology community and runs
the South Colorado .NET user group. He also
enjoys speaking at tech groups and events around
the country.
Ben Hoelting
@benhnet
b.hoelting@aspenware.com

3. Day I Agenda
• TFS Overview
• TFS Version Comparison and Installation
• Setting Up Your Code in TFS Source Control
• Setting Up Your Code in Git Source Control
• Scrum Overview
• Sprint 0 Activities
• Sprint Planning Exercise
• Summary and Wrap Up
3Aspenware: Scrum with TFS – Day I

4. TFS Overview and Initial Setup
4Aspenware: Scrum with TFS – Day I

5. What is Team Foundation Service?

6. Team Foundation Service Core
Capabilities

7. Agile Planning & Management
7

8. Web UI
Access burndown, task tracking, team notices
8

9. Work Items
9

10. Build Management & Automation
Aspenware: Scrum with TFS – Day I 10

11. Easy (no infrastructure)
Supports testing (multiple frameworks)
Supports 3rd party binaries (in version control or via
NuGet)
Software & completion restrictions
Continuous deployment to Azure, automatically
Using the Hosted Build Controller

12. Version Control
Enterprise-class Version control
Version anything, integrated check-in, annotation, distributed teams support,
shared check-outs, check-in policies. Sync with Git
Flexible branching & merging
Path-space branching, branch visualization, merge tracking
Collaborative
Annotation, code reviews, inline compare/merge
Focused on productivity
Online/offline, bridges with other VC tools, shelving, VS suspend/resume 12

13. TFS Version Comparison & Installation
13Aspenware: Scrum with TFS – Day I

14. Frank
Mbanusi
Frank is a United States Marine. It’s no wonder
that he’s driven by mission accomplishment. He
is committed to cultivating healthy and trusting
relationships with our clients – It’s about people!
Frank enjoys his family, friends, fitness, and
music. Frank Mbanusi
Strategic Account Executive
f.mbanusi@aspenware.com
@vMbanusi

15. Team Foundation Server Editions
15
• Team Foundation Server Express
• Team Foundation Server
• Team Foundation Service (tfs.visualstudio.com)
Aspenware: Scrum with TFS – Day I

16. Team Foundation Server Express – Pros
16
• Free
• Data stays in network
• Comes with version control repository
• More control compared to TF Service
• Process and Work Item template customization
• CAL option if team grows beyond 5 users
• Support for express versions of VS
Aspenware: Scrum with TFS – Day I

17. Team Foundation Server Express – Cons
17
• Must have own hardware or virtual machine
• Not accessible from anywhere
• Basic installation on one machine only – no scale
• Limited Agile PM features and tools
• No SharePoint or Reporting Services integration
• Supports only SQL Server Express Edition
• Database maintenance
• Licensing for OS and CALs if required
Aspenware: Scrum with TFS – Day I

18. Team Foundation Server – Pros
18
• Full integration with products like SharePoint and SQL Server
Reporting Services
• Supports higher end versions of SQL Server for the backend,
as well as Express
• Supports the express versions of Visual Studio and other non-
Microsoft products (CALs may be required)
• CAL License is included with certain Visual Studio subscriptions
(Pro, Prem, and Ult)
Aspenware: Scrum with TFS – Day I

19. Team Foundation Server – Cons
19
• Must have own hardware and/or virtual machines
• Requires installation and configuration
• Requires purchased CALs as needed
• More expensive for small teams
• Not accessible from anywhere (unless published externally)
Aspenware: Scrum with TFS – Day I

20. Team Foundation Service – Pros
20
• No installation – up and running in minutes
• No hardware or software
• Data stored in triplicate on three physically distinct servers
• No backup management
• Service accessible from anywhere around the world
• Updated every 3 weeks
• No licensing required when using express versions of VS or
non-Microsoft platforms such as Eclipse or Xcode
• Scalable
Aspenware: Scrum with TFS – Day I

21. Team Foundation Service – Cons
21
• Free for up to 5 users (no paid version plan yet)
• No Active Directory support
• Performance with file transfers depending on connection speed
• Data is not inside your network
• No process template or work item template customization
• No SharePoint integration
• No Lab environment
• Limited reports – can’t deploy custom reports
• Limited migration path from TFS on prem to TF Service
Aspenware: Scrum with TFS – Day I

22. TFS On-Premise vs. Cloud (TF Service)
Aspenware: Scrum with TFS – Day I 22
Team Foundation Server Team Foundation Service

23. System Requirements for TFS
• Operating System Requirements
• 64-bit versions of Server 2008 SP2, Server 2008 R2 SP2 and 64-bit Server 2012
• Server Core not supported
• Client Operating Systems
• 64-bit or 32-bit versions of Windows 7 SP1 and Windows 8
• Hardware Recommendations
• Fewer than 250 users – Single Server, 1 x single core 2.13GHz, 2GB, 125GB/7.2k rpm
• 250 – 500 users – Single Server, 1 x dual core 2.13GHz, 4GB, 300GB/10k rpm
• 500 – 2,200 users – Dual Server, 1 x dual core Intel Xeon 2.13GHz, 4GB, 500GB/7.2k rpm –
SQL: 1 x quad Intel Xeon 2.33GHz, 4GB, 500GB/7.2k rpm
• SharePoint hardware recommendations
• Virtualization recommendations – Microsoft support
• http://msdn.microsoft.com/en-us/library/vstudio/dd578592.aspx
23Aspenware: Scrum with TFS – Day I

24. Active Directory Requirements
• Domain or Workgroup members supported
• Supported Functional Levels
• Windows 2000 native mode
• Windows Server 2003 mode
• Windows Server 2008 mode
24Aspenware: Scrum with TFS – Day I

25. SQL Server Requirements for TFS
• Supported Editions
• SQL Server 2008 R2 Express, Standard and Enterprise SP1 CU1
• SQL Server 2012 Express, Standard and Enterprise
• Features required
• Database Engine Service
• Full-Text Search
• Reporting features required
• Reporting Services (Native for 2012)
• Analysis Services
• Authentication
• Windows
• Service account
• Domain or Local built in account
25Aspenware: Scrum with TFS – Day I

26. Configuration Options for TFS
• Basic Configuration
• Install SQL Server Express or Use an existing SQL Server instance
• Standard Configuration
• Domain account required for SP service account (also used as Report Reader account)
• Member of Administrators security group
• Best practices around service accounts (SP, SQL, TFS) - http://msdn.microsoft.com/en-
us/library/vstudio/dd578625.aspx
• Advanced Configuration
• Multiple server configuration
• No built-in accounts for service accounts
• Ensure supported hardware/software
• Ensure proper permissions and service accounts
• Set up SQL (SSRS, SSAS), SharePoint (w/ TFS and TFS Extensions), and TFS (TFS Config Tool)
• https://www.smashwords.com/books/view/307722
26Aspenware: Scrum with TFS – Day I

27. Setting Up Your Code in TFS Source
Control
27Aspenware: Scrum with TFS – Day I

28. Branching, in revision control and software configuration
management, is the duplication of an object under revision control (such as a source
code file, or a directory tree) so that modifications can happen in parallel along both
branches
http://en.wikipedia.org/wiki/Branching_(software)
Aspenware: Scrum with TFS – Day I 28

29. Forward Integration (FI) &
Reverse Integration (RI)
DEVELOPMENT
MAIN
Branch
Reverse
Forward
Aspenware: Scrum with TFS – Day I 29

30. It’s All About the Main Branch
Aspenware: Scrum with TFS – Day I 30

31. Creating Main
Aspenware: Scrum with TFS – Day I 31

32. Development Branch
•Changes for next version of work.
Aspenware: Scrum with TFS – Day I 32

33. Adding Code
Aspenware: Scrum with TFS – Day I 33

34. Setting Up Your Code using Git Source
Control
34Aspenware: Scrum with TFS – Day I

35. Ely
Lucas
e.lucas@aspenware.com || Senior Software Developer
Ely is a software developer by day and ninja by night. He has over
10 years experience delivering cutting edge solutions and sneaking
around unnoticed. He enjoys sharing his knowledge with others,
technology, being outdoors and levitating objects with his mind. He
lives in Denver with his wife, son and dog.

36. Git is an open source distributed version control system designed for
speed and efficiency
Git is an open source distributed version control system designed
for speed and efficiency
Git is an open source distributed version control system
designed for speed and efficiency
Git is an open source distributed version control system designed for
speed and efficiency
What Is Git?
Aspenware: Scrum with TFS – Day I 36

37. Central Source Control Server
Repo
Version 3
Version 2
Version 1
Developer A
Developer B
File
File
Checkout
Checkout
Aspenware: Scrum with TFS – Day I 37

38. Developer A
Repo
Version
3
Version
2
Version
1
Developer B
Repo
Version
3
Version
2
Version
1
Developer C
Repo
Version
3
Version
2
Version
1
Server
Repo
Version
3
Version
2
Version
1

39. Common Git commands
• Init
• Add
• Commit
• Branch
• Checkout
• Merge
• Push/Pull
• Status
• Reset
Aspenware: Scrum with TFS – Day I 39

40. Break
40Aspenware: Scrum with TFS – Day I

41. Scrum Overview
41Aspenware: Scrum with TFS – Day I

42. Ken
Payne
k.payne@aspenware.com || Delivery Director || 303.590.4390
Ken gets inspiration and energy by working alongside smart, creative
people solving tough business problems and wowing clients. He
believes great solutions evolve through focused collaboration and
strongly supports the notion that "innovation is a team sport."

43. Scrum is Value Driven
43
Constraints
Variable
Plan Driven
Value Driven
Features Cost Schedule
FeaturesCost Schedule
Traditional Scrum
Aspenware: Scrum with TFS – Day I

44. Scrum is Iterative
44
Sprint Planning
Sprint Review
Scrum
Update the
Task
Code
Check-in
Product
Vision
Product
Backlog
Sprint
Backlog
2 – 4
weeks
24
hours
Sprint Retrospective
Test
Potentially Shippable*
Product
Backlog
Grooming
“Scrum 0”
Aspenware: Scrum with TFS – Day I

45. Scrum is Iterative and Incremental
45
Drawings by Jeff Patton
Aspenware: Scrum with TFS – Day I

46. Scrum Teams are Cross-Functional
46
The Scrum team is self-organizing and
cross-functional with all the skills
necessary to create a product increment
Product OwnerScrum MasterDevelopment Team
Aspenware: Scrum with TFS – Day I

47. Scrum is simple…
47
…to understand,
difficult to do well
Aspenware: Scrum with TFS – Day I

48. Estimating Precision
48
Accuracy
Understanding
Themes or
Epics
(T-shirt sizes)
User Stories
(Story points)
Tasks
(Hours)
Future SprintRelease / Product
“There's no sense in being
precise when you don't even
know what you're talking about.”
– John von Neumann
Priority
Aspenware: Scrum with TFS – Day I

49. Sprint 0 Activities
49Aspenware: Scrum with TFS – Day I

50. Sally
Tait
s.tait@aspenware.com || Senior Consultant || 303.798.5458
Sally is a problem solver and information collector. From optimizing
the way her kitchen is organized to modeling complex business
processes, she is compelled to design systems that simplify getting
things done.

51. Sprint 0: Definition
51
Sprint 0:
Discovery
Sprint 1,2,3:
Development
Sprint 4:
Release
• Meet with key stakeholders to
build the product backlog.
• Set up Development and QA
environments.
• Set up the baseline
architecture, continuous
integration architecture and
framework for nightly
deployments
• Set up project infrastructure
and conventions, schedule
project activity and track and
report progress.
1 week 12 weeks 1 week
• Perform sprint planning
• Complete work item tasks
• Run daily standups, schedule project activity, and track and report
progress.
• Perform unit and integration testing.
• Auto deploy nightly
• QA test daily
• Perform end of Sprint demo
• Perform sprint retrospective
• Provide technical and user
support for release
• Run daily standups, schedule
project activity, and track and
report progress
Aspenware: Scrum with TFS – Day I

52. Sprint 0: Project and Team Definition
• Project Templates
• Agile
• Scrum
• CMMI (traditional waterfall)
• Teams and Areas
• Flexible categorization of the work
• Teams are used to segment groups of people
• Areas can be used to segment the work
52Aspenware: Scrum with TFS – Day I

53. Sprint 0: Set Up Iterations (Sprints)
• Sprints or Iterations
• Timeboxes of work from the backlog
• Each should each have same duration
• Look at velocity to determine scope of each sprint
• Releases
• Each sprint will produce “shippable” code.
• Several sprints may be completed before an actual release.
53Aspenware: Scrum with TFS – Day I

54. Demo: Projects, Teams, Areas and
Iterations
54Aspenware: Scrum with TFS – Day I

55. Sprint 0: Define the Backlog
• Product Backlog
• Contains requirements, ideas, wish list, enhancements, bugs, etc.
• Anyone can add to the product backlog.
• Only the Product Owner can prioritize the product backlog.
• TFS has security settings and alerts to manage this if desired.
55Aspenware: Scrum with TFS – Day I

56. Sprint 0: Define the Backlog
• Work Item Types in TFS
• Product Backlog Item (PBI) – Requirement or Desired Feature
• Task - Thing to do related to PBI
• Bug - Defect or issue found in the application
• Impediment - something that is causing a delay
• Test Case - List of steps a tester should take to validate a PBI
56Aspenware: Scrum with TFS – Day I

57. Sprint 0: Define the Backlog
• User Story Format
• Backlog items should be expressed in business terms.
• Most common format is user story:
As a [role],
I want to [do something],
so that I can [achieve a desired result]
57Aspenware: Scrum with TFS – Day I

58. Demo Adding PBIs
58Aspenware: Scrum with TFS – Day I

59. Sprint 0: Size and Prioritize
• Sizing the Product Backlog Items
• Sizing is a team effort.
• Rather than ask "how long will it take," you ask, "how big is it?“
• Common to use the Fibonacci sequence.
• 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144...
• Simplified variation: 1, 2, 3, 5, 8, 13, 20, 40 (no higher)
• Backlog prioritization
• Only the Product Owner may prioritize the backlog.
• Simple list order, rather than 1, 2, 3 categories.
59Aspenware: Scrum with TFS – Day I

60. Demo Sizing and Prioritization
60Aspenware: Scrum with TFS – Day I

61. Break
61Aspenware: Scrum with TFS – Day I

62. Sprint Planning
62Aspenware: Scrum with TFS – Day I

63. Plan the Sprint
• If not already determined, determine the duration and number of sprints
• Establish the sprint goal
• Add PBIs to the sprint from the prioritized backlog
• Set team capacity
• Add tasks and task estimates to PBIs
• Resolve over-allocations
• Commit!*
63Aspenware: Scrum with TFS – Day I

64. Sprint Planning Demo
64Aspenware: Scrum with TFS – Day I

65. Wrap up
• What we talked about
• TFS Overview
• TFS Version Comparison and Installation
• Setting Up Your Code in TFS Source Control
• Setting Up Your Code in Git Source Control
• Scrum Overview
• Sprint 0 Activities
• Sprint Planning Exercise
• Review items in the Parking Lot
• Visit http://www.aspenware.com/blog for the slides and any additional resources
• B.Hoelting@Aspenware.com
65Aspenware: Scrum with TFS – Day I

66. End of Day I
66Aspenware: Scrum with TFS – Day I