Downloaded 413 times
![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](https://image.slidesharecdn.com/tfstrainingclasspresentationmaster-130922150338-phpapp01/85/Implementing-Scrum-with-Microsoft-Team-Foundation-Service-TFS-57-320.jpg)
Uploaded byAspenware
Implementing Scrum with Microsoft Team Foundation Service (TFS)
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.
More Related Content
Similar to Implementing Scrum with Microsoft Team Foundation Service (TFS)
Implementing Scrum with Microsoft Team Foundation Service (TFS)
- 1. Day I Implementing Scrumwith Microsoft Team Foundation Service (TFS)
- 2. Ben Hoelting In truth, he’sjust 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 andInitial Setup 4Aspenware: Scrum with TFS – Day I
- 5. What is TeamFoundation Service?
- 6. Team Foundation ServiceCore Capabilities
- 7. Agile Planning &Management 7
- 8. Web UI Access burndown,task tracking, team notices 8
- 9.
- 10. Build Management &Automation Aspenware: Scrum with TFS – Day I 10
- 11. Easy (no infrastructure) Supportstesting (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 Versioncontrol 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 aUnited 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 ServerEditions 15 • Team Foundation Server Express • Team Foundation Server • Team Foundation Service (tfs.visualstudio.com) Aspenware: Scrum with TFS – Day I
- 16. Team Foundation ServerExpress – 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 ServerExpress – 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 forTFS • 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 Requirementsfor 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 forTFS • 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 YourCode in TFS Source Control 27Aspenware: Scrum with TFS – Day I
- 28. Branching, in revisioncontrol 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 Aboutthe Main Branch Aspenware: Scrum with TFS – Day I 30
- 31. Creating Main Aspenware: Scrumwith TFS – Day I 31
- 32. Development Branch •Changes fornext version of work. Aspenware: Scrum with TFS – Day I 32
- 33. Adding Code Aspenware: Scrumwith TFS – Day I 33
- 34. Setting Up YourCode using Git Source Control 34Aspenware: Scrum with TFS – Day I
- 35. Ely Lucas e.lucas@aspenware.com || SeniorSoftware 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 anopen 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 ControlServer 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 DeveloperC 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 withTFS – Day I
- 41. Scrum Overview 41Aspenware: Scrumwith TFS – Day I
- 42. Ken Payne k.payne@aspenware.com || DeliveryDirector || 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 ValueDriven 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 SprintPlanning 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 Iterativeand Incremental 45 Drawings by Jeff Patton Aspenware: Scrum with TFS – Day I
- 46. Scrum Teams areCross-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 …tounderstand, difficult to do well Aspenware: Scrum with TFS – Day I
- 48. Estimating Precision 48 Accuracy Understanding Themes or Epics (T-shirtsizes) 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 || SeniorConsultant || 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 Sprint0: 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: Projectand 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: SetUp 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: Definethe 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: Definethe 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: Definethe 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: Sizeand 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 andPrioritization 60Aspenware: Scrum with TFS – Day I
- 61. Break 61Aspenware: Scrum withTFS – Day I
- 62. Sprint Planning 62Aspenware: Scrumwith 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 • Whatwe 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 DayI 66Aspenware: Scrum with TFS – Day I
Editor's Notes
- #29 Agree on definition of branching.
- #30 It’s important that we get some basic terms down before we go any further. AS you can see here the MAIN branch contains completed functionality that has passed integration tests, and the DEVELOPMENT branch contains the code that is under construction. We initially BRANCH from MAIN to DEVELOPMENT in order to get a base set of code established between the two.When a new functionality in the DEVELOPMENT branch is completed and can pass integration tests, you can promote the code from the DEVELOPMENT branch to the MAIN branch. This process is referred to as REVERSE INTEGRATION. Conversely, if you merge the code from the MAIN branch to the DEVELOPMENT branch, the process is referred to as FORWARD INTEGRATION.
- #31 Throughout this talk you will notice one overarching theme: Everything centers around the Main Branch (as the name implies).Keep this in mind as we continue to show various scenarios. Main is the junction branch between the development and release branches. This branch should represent a stable snapshot of the product that can be shared with QA or external teams. Changes in the MAIN branch will merge (FI) into every DEVELOPMENT branch (shown later), so it is critical that builds from MAIN remain high quality. At minimum this means MAIN must remain buildable and pass all build verification tests Attributes of MAIN Main should build daily to give the team a daily cadence to work toward. Every branch should have a natural merge (RI) path back to MAIN (i.e. no baseless merges). Breaks in MAIN need to be fixed immediately. No direct check-ins to MAIN branch; only build and BVT fixes. Successful MAIN build indicates child DEVELOPMENT branches should merge (FI) from MAIN. QA teams should be able to pick up any MAIN build for testing. Some teams are small enough that they think only one branch, MAIN, is needed. This will work but is almost always short-lived. Eventually individuals or teams will need some sort of isolation to work on next version work, complicated bug fixes or breaking changes. If you do not create a specific place for development work, developers will create their own. The danger here is that the ad-hoc branch created by the developer may not have a natural branch path back to MAIN. Since these situations are inevitable it is best to have the development branch plan ready when needed. If ever you need advice on when to branch, think of this: Create a new branch when the check-in policy is so restrictive you can’t do work. This means when the check in policy of your MAIN branch is to take version 1.0 changes only and you have a version 1.1 changes then that would be a good signal to create a child branch of MAIN for your 1.1 work.
- #32 DEMO NOTES:Create a new blank project in TFS if you have not already done so. Map the project to your local drive.Add a folder named Main.Check-in your changes.Right-click on Main and go to Branching and Merging | Convert to branch.Click Convert in the Convert to branch dialog.
- #33 Branching enables parallel development by providing each development activity for the current release its own self-contained snapshot of needed sources, tools, external dependencies and process automation. Such a self-contained snapshot effectively enables each development activity to proceed at its own pace, without taking any dependency on another. It follows that these snapshots are allowed to diverge their respective sources along the particular development activity they are involved with – fixing a bug, implementing a feature, or stabilizing a breaking change. Before creating a DEVELOPMENT branch, make sure you can do the following: Select a parent branch – if your changes are focused on your next product release then the parent branch should be MAIN. Branch from a recent known good state of the parent – start your branch from the latest successful build of the parent branch. There should be a label associated with the parent build that you can use as a starting point for your child branch. On day one of your DEVELOPMENT branch it should be in the same state as its parent (i.e. build and pass BVTs successfully). Merge (FI) frequently – your goal should be to be no more than 1-2 days out of sync with MAIN. Ideally you should merge (FI) every time the parent branch builds and passes BVTs. Merge (RI) from child to parent based on quality. Minimum merge (RI) requirements are o Be in sync with parent branch o Build successfully o Pass BVTs DEVELOPMENT (DEV) branches for next version work: a. Focus on wide, flat branches to enable steady code flow to MAIN and then back to peer DEVELOPMENT branches b. Work in DEVELOPMENT branches can be isolated by feature, organization, or temporary collaboration. c. Each DEVELOPMENT branch should be a full branch of MAIN. d. DEVELOPMENT branches should build and run Build Verification Tests (BVTs) the same way as MAIN. e. Forward Integrate (Merge (FI) with each successful build of MAIN f. Reverse Integrate (RI) Code flow, the movement of changes between child and parent branches, is a concept all team members must consider. As the number of DEVELOPMENT branches increases, the need to merge (FI) following each successful MAIN build increases. Any DEVELOPMENT branch that is more than a couple days out of sync with MAIN is effectively working in the past.
- #34 Now that we have created our branches and folder structure let’s add some code to our development branch.Create a new Console application and call it whatever you like make sure to check it into source control and put it in the Development branch in the Src folder.Add a little code to the application and build / run it.Check in your changes.
- #37 it!
- #54 PROJECT AND TEAM DEFINITIONCreate ProjectSelect TemplateTour the Home pageAdd MembersAdminister Account TeamsAreasOrganize sprints and releases Add sprintEnter start and end dates
- #58 Build the Product BacklogView Backlog - tour the screenAdd 3-4 PBIs Click on PBI.Tour the screen.Iteration, Status.Acceptance CriteriaTest Cases - steps to validate for acceptance
- #60 Open a PBI and add the effort size. Do this for several PBIsIn the Backlog, talk about ways to prioritize. Turn forecasting on and off.