T HE E X P ER T ’S VOIC E ® IN .NE T Agile Project Management Using Team Foundation Server 2015 — Joachim Rossberg Agile Project Management Using Team Foundation Server 2015 Joachim Rossberg Agile Project Management Using Team Foundation Server 2015 Joachim Rossberg Goteborg, Sweden ISBN-13 (pbk): 978-1-4842-1869-3 ISBN-13 (electronic): 978-1-4842-1870-9 DOI 10.1007/978-1-4842-1870-9 Library of Congress Control Number: 2016940378 Copyright © 2016 by Joachim Rossberg This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Exempted from this legal reservation are brief excerpts in connection with reviews or scholarly analysis or material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work. Duplication of this publication or parts thereof is permitted only under the provisions of the Copyright Law of the Publisher’s location, in its current version, and permission for use must always be obtained from Springer. Permissions for use may be obtained through RightsLink at the Copyright Clearance Center. Violations are liable to prosecution under the respective Copyright Law. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. The publisher makes no warranty, express or implied, with respect to the material contained herein. Managing Director: Welmoed Spahr Lead Editor: James DeWolf Development Editor: Douglas Pundick Technical Reviewer: Fabio Claudio Ferracchiati Editorial Board: Steve Anglin, Pramila Balen, Louise Corrigan, Jim DeWolf, Jonathan Gennick, Robert Hutchinson, Celestin Suresh John, James Markham, Susan McDermott, Matthew Moodie, Jeffrey Pepper, Douglas Pundick, Ben Renow-Clarke, Gwenan Spearing Coordinating Editor: Melissa Maldonado Copy Editor: Keia Endsley Compositor: SPi Global Indexer: SPi Global Artist: SPi Global Distributed to the book trade worldwide by Springer Science+Business Media New York, 233 Spring Street, 6th Floor, New York, NY 10013. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail orders-ny@springer-sbm.com, or visit www. Apress Media, LLC is a California LLC and the sole member (owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance Inc is a Delaware corporation. For information on translations, please e-mail rights@apress.com, or visit www. Apress and friends of ED books may be purchased in bulk for academic, corporate, or promotional use. eBook versions and licenses are also available for most titles. For more information, reference our Special Bulk Sales–eBook Licensing web page at www.com/bulk-sales. Any source code or other supplementary material referenced by the author in this text is available to readers at www. For detailed information about how to locate your book’s source code, go to www.com/source-code/. Printed on acid-free paper This one is for Amelie, Eddie, and Karin. Contents at a Glance About the Author . xiii About the Technical Reviewer .xix ■Chapter 1: Introduction to Application Lifecycle Management . 1 ■Chapter 2: An Overview of TFS . 19 ■Chapter 3: Introduction to Scrum and Agile Concepts . 37 ■Chapter 4: Work Items and Process Templates . 65 ■Chapter 5: Customizing the Process Template in TFS . 87 ■Chapter 6: Agile Practices in TFS . 117 ■Chapter 7: Metrics in Agile Projects . 131 ■Chapter 8: Agile Project Management in TFS . 187 v Contents About the Author . xiii About the Technical Reviewer .xix ■Chapter 1: Introduction to Application Lifecycle Management . 1 Aspects of the ALM Process . 1 Four Ways of Looking at ALM . 4 The SDLC View. 5 The Service Management or Operations View . 6 The Application Portfolio Management View . 6 The Unified View . 7 Three Pillars of Traditional Application Lifecycle Management . 8 Automation of High-Level Processes . 8 Visibility into the Progress of Development Efforts . 9 A Brief History of ALM Tools and Concepts. 9 Application Lifecycle Management 1. 10 Application Lifecycle Management 2. 12 Application Lifecycle Management 2. 18 vii ■ CONTENTS ■Chapter 2: An Overview of TFS . 19 Application Lifecycle Management Overview . 19 Team Foundation Server Overview . 20 Team Foundation Server. 22 Visual Studio 2015 Editions . 24 Integrated Development Environment (IDE) Integration . 25 The TFS Work Item Tracking System . 31 Work Items for Collaboration . 32 The Gap Between IT and Business . 33 Use of One Role-Based Tool . 34 Differences Between TFS and VSTS . 35 ■Chapter 3: Introduction to Scrum and Agile Concepts . 37 The Scrum Framework . 37 Empirical Process Control. 38 Complexity in Projects . 39 What Scrum Is . 40 Roles in Scrum . 42 The Scrum Process. 43 Definition of Done . 46 Agile Requirements and Estimation . 48 During the Sprint . 51 viii ■ CONTENTS Kanban . 53 Start With What You Do Now . 54 Agree to Pursue Incremental, Evolutionary Change . 54 Respect the Current Process, Roles, Responsibilities, and Titles . 54 The Five Core Properties . 54 Common Models Used to Understand Work in Kanban . 59 Scaled Professional Scrum (SPS) . 61 How Agile Maps to ALM . 63 Agile Captures Task-Based Work . 63 Increased Frequency of Inspection . 63 Many Tools Collect Much Information . 63 Test Artifacts Are Important . 64 Agile Teams Plan Frequently. 64 ■Chapter 4: Work Items and Process Templates . 66 The TFS Work Item Tracking System . 67 The Process in TFS . 76 Agile, CMMI, and Scrum. 85 ix ■ CONTENTS ■Chapter 5: Customizing the Process Template in TFS . 87 Modifying the Process Template In TFS On-Premise . 87 Common Adaptations of the Process Template . 90 Modifying the Process Template in Visual Studio Team Services . 115 ■Chapter 6: Agile Practices in TFS . 119 Clients for Managing Tests . 120 Test-Driven Development . 122 Working with Automated Tests . 123 Why Continuous Integration?. 129 ■Chapter 7: Metrics in Agile Projects . 131 Project-Management Metrics. 131 Metrics for Architecture, Analysis and Design . 136 Metrics for Developer Practices . 137 Code Analysis Warnings. 138 x ■ CONTENTS Metrics for Software Testing . 138 Metrics for Release Management . 141 Using Charts to Monitor Metrics. 145 ■Chapter 8: Agile Project Management in TFS . 147 The Pilot Project . 148 TFS/VSTS Web Portal . 149 Charts and Queries . 150 Project Startup Phase. 152 PO Sets Off to Work . 152 Building the Initial Team . 153 Creating New Teams . 154 The Backlog and Team Structure for the Fabrikam Pilot . 157 Building the Teams . 158 Adding Team Members . 159 Managing VSTS Groups, Teams, and User’s Permission. 163 Building the Backlog. 164 Definition of Done (DoD) . 168 Refining the Backlog . 169 xi ■ CONTENTS Initial Velocity . 169 Capacity Planning in TFS . 170 Initial Sprint Planning . 171 Updating Backlog and PBI . 172 Forecast in TFS . 175 Estimated Time Plan . 176 Estimated Project Cost . 176 Scrum Meetings During the Sprint . 177 Daily Stand-Up . 182 Retrieving Data from TFS/VSTS . 187 xii About the Author Joachim Rossberg has worked as an IT consultant since 1998. He is primarily a product owner and project manager, but has an extensive history as a system developer/designer. Joachim is a certified Scrum Master and Product Owner. He has also demonstrated his technical background with various achievements over the years, including MCSD, MCDBA, MCSA, and MCSE. His specialties include agile project management, ALM processes, and Team Foundation Server. Joachim now works for Solidify in Gothenburg, Sweden. xiii About the Technical Reviewer Fabio Claudio Ferracchiati is a senior consultant and a senior analyst/developer using Microsoft technologies. He works for Blu Arancio (www. He is a Microsoft Certified Solution Developer for .NET, a Microsoft Certified Application Developer for .NET, a Microsoft Certified Professional, and a prolific author and technical reviewer. Over the past 10 years, he’s written articles for Italian and international magazines and coauthored more than 10 books on a variety of computer topics. xv Acknowledgments Thanks to everyone who helped me through this book. No one mentioned, no one forgotten. Except for one person I want to thank especially. Mathias Olausson, my coworker and manager, who wrote a great book on Continuous Delivery with Visual Studio ALM 2015 for Apress. Check it out at http://www.com/ Continuous-Delivery-Visual-Studio-2015/dp/1484212738/ref=sr_1_1?ie=UTF8&qid=1461920928&sr= 8-1&keywords=mathias+olausson. xvii Introduction This book covers agile project management using Team Foundation Server and Visual Studio Team Services. It provides many examples from both of these versions of TFS. However, this is not a hands-on book, instead it is aimed at providing useful information especially for product owners so that they know what TFS is and how it can be used in an agile world. xix CHAPTER 1 Introduction to Application Lifecycle Management What do you think about when you hear the term Application Lifecycle Management (ALM)? During a seminar tour in 2005 in Sweden, presenting on Microsoft Visual Studio Team System, we asked people what ALM was and whether they cared about it. To our surprise, many people equated ALM with operations and maintenance. This is still often the case when we visit companies, although more people today are aware of the term. Was that your answer as well? Does ALM include more than just operations? Yes, it does. ALM is the thread that ties the development lifecycle together. It involves all the steps necessary to coordinate development lifecycle activities. Operations are just one part of the ALM process. Other elements range from requirements gathering to more technical things like the build and deploy processes. Aspects of the ALM Process All software development includes various steps performed by people playing specific roles. There are many different roles, or disciplines, in the ALM process, and we define some of them in this section. (The process could include more roles, but we focus on the primary ones.) Look at Figure 1-1, which illustrates ALM and some of its aspects. You can see the flow from the birth of an application, when the business need first arises, to when the business need no longer exists and the application dies. Once the thought of a new application (or system) is born, many organizations do some portfolio rationalization. This means you discuss whether an existing system can handle the need or whether a new system has to be developed. If a new system must be built, you enter the software development lifecycle (SDLC) and develop the system, test it, and deploy the system into operation. This is the point at which you do a handover so that operations can maintain and refine the system. Once in production, the system (hopefully) delivers the intended business value until retirement. While in operation, the system usually is updated or undergoes bug fixes; at such times, change requests (CRs) are written. For each CR, you go through the same process again. Rossberg, Agile Project Management using Team Foundation Server 2015, DOI 10.1007/978-1-4842-1870-9_1 CHAPTER 1 ■ INTRODUCTION TO APPLICATION LIFECYCLE MANAGEMENT Figure 1-1. The Application Lifecycle Management process It’s essential to understand that all business software development is a team effort. The roles require collaboration in order to deliver business value to the organization.
