© ThoughtWorks, 2007 The TW Agile template for VSTS Microsoft Architect Insight Conference – 2007 Nick Hines ThoughtWorks

© ThoughtWorks, 2006 Introduction The session will cover: – Introduction to TW Agile – Iteration planning and estimation – Work items including stories, tasks and bugs – Reports and tracking including burn down charts, velocity charts, and bug reporting – VSTS and CruiseControl

© ThoughtWorks, 2006 ThoughtWorks at a glance Reach United Kingdom United States Australia India Canada China Industries Asset Finance Insurance Retail Mortgage Banking Expertise.NET Java SOA EAI Open Source Agile Distributed Agile Services Deliver Transform Advise Select Clients Bank of America Caterpillar Financial St Paul Travelers CNA Dixons Nationwide Size 700 employees $85 M in revenue

© ThoughtWorks, 2006 What makes TW Agile different? Given the loose definition of agile, many methodologies fall into this category: Some are more extreme in their definitions Hybrid approaches like ThoughtWorks Agile work well if they are sympathetic to their roots.

© ThoughtWorks, 2006 When to use TW Agile More Strict More Agile Waterfall RUP XP RAD TW Agile TW Agile TW Agile: Not as radical as XP, but incorporating many XP practices such as pair programming, TDD, Continuous Integration, etc. Scrum Crystal Clear Crystal Clear

© ThoughtWorks, 2006 Process Guidance

© ThoughtWorks, 2006 Roles and Responsibility Key roles within delivery: – Analyst: Responsible for identifying and defining the project requirements as stories and tasks, and supporting those stories through development to sign- off. – Developer: Responsible for implementing stories and tasks to ensure that technical tasks (e.g. environmental, spikes) and business requirements (stories) are delivered. – QA: Responsible for defining the acceptance criteria for each story and for functionally testing the story to ensure it is complete and bug free. – Project Manager: Responsible for managing project activity and tracking project progress and reporting progress internally to the team and externally to the client.

© ThoughtWorks, 2006 What about the Architect? –What is the role of an architect on an Agile project? »“cuts” code – no ivory towers! »maintains overall system architecture vision »final word on disputed design decisions »interacts with customer and customer IT staff as appropriate »responsible for successful delivery of the application

© ThoughtWorks, 2006 The role of the story The role of a story is to record a functional requirement. Stories are written in a specific format that identifies the requirement, user and business value of the requirement “As a…….I want…….so that…….” – An example from an online banking project could be: “As a current account holder, I want to be able to see my bank balance online so that I can see how much money I have to spend”. This format ensures that each requirement has a clear role (or roles) associated with it’s use, and a view of it’s importance to the business. This helps differentiate ‘essential’ from ‘nice to have’ features. Stories are given a priority and an estimate so that they can be scheduled for development. The story is only fully analysed once it has been selected for development in the next iteration.

© ThoughtWorks, 2006 Finding stories Stories are identified using a ‘workshop’ based approach and traditional business analysis activities. Analysis is carried out in a light-weight manner using whiteboards cards and post-its. Outputs include: – Process Maps/Models – State change diagrams – UI Prototypes – Information Architectures These outputs are then used as the basis for story writing sessions – “at this step in the process, what is it you actually want to be able to do”

© ThoughtWorks, 2006 Capturing stories in VSTS Unique identifier for story Short title of story. Use ubiquitous language, (DDD) User persona requesting story Description of business functionality required Description of business value achieved by story Release and iteration in which story is “played” Customer priority for story Developer estimate of story size What does the system have to do for this story to be complete? Initial story state

© ThoughtWorks, 2006 Estimating & Prioritising stories Estimation is undertaken by the developers who will be responsible for delivering the requirements Estimates are given to each story Prioritisation is done by the business A priority is given to each story

© ThoughtWorks, 2006 Release Planning Release planning is achieved by assigning stories to a release based on their priority and estimate. Stories are often moved between releases based on project progress and changing project priorities. No specific tool support yet

© ThoughtWorks, 2006 The importance of Story Cards Visibility is a key aspect to ThoughtWorks methodology Physical cards are pinned to a ‘story wall’ so that it is visible to all at a glance what is happening in the current iteration, and what is planned for the next iteration. The card wall becomes a place of congregation for stand-ups and status meetings.

© ThoughtWorks, 2006 Story Card from VSTS

© ThoughtWorks, 2006 The Master Story List (MSL)

© ThoughtWorks, 2006 Story Lifecycle New Signed-off QA Complete QA Complete Dev Complete Dev Complete Analysis Complete Analysis Complete Defined Add title, description, priority and estimate Add Acceptance Criteria and other required information Develop story Test developed code/functionality Business review

© ThoughtWorks, 2006 Stories and Tasks Stories are functional requirements Capture non-functional requirements, (such as performance) as stories Stories will require a number of development tasks to achieve e.g. build a screen, create a DB table, etc. Tasks include environmental, build & deployment tasks, spikes, etc. All tasks relate to a story

© ThoughtWorks, 2006 Risk and Issues Risks – A risk is an anticipated event which has the potential to impair successful project delivery Issues – An issue is an event, whether anticipated or not, which has impaired or is now impairing successful project delivery Risks and issues can be technical, (e.g. insufficient test environments) as well as business driven (e.g. insufficient time with key stakeholders)

© ThoughtWorks, 2006 Risk Management Cycle Brainstorm & triage Probability, Cost & Impact Countermeasures & Triggers Execute mitigating actions Continue to monitor risk Execute contingency

© ThoughtWorks, 2006 Capturing Issues in VSTS Identifier for issue State of issue: - initially Open Priority of issue – Low, Medium, High Textual description of issue Actions to be taken to mitigate issue

© ThoughtWorks, 2006 Issue Log

© ThoughtWorks, 2006 Capturing Bugs in VSTS Title of Bug Story that bug relates to State of bug – initially Open Priority of bug- High, Medium, Low Number of build in which bug detected Estimated effort to resolve bug Actual effort required to resolve bug Build in which bug is resolved Detailed description of bug Detailed steps to recreate bug

© ThoughtWorks, 2006 Project Tracking & Reporting TW Agile template provides high project visibility Different projects may require different levels of reporting Template provides number of charts for project tracking e.g. velocity, yesterday’s weather, bug tracking, etc. Other reports can be easily generated using SQL Reporting Services

© ThoughtWorks, 2006 Project Velocity

© ThoughtWorks, 2006 Yesterday’s weather

© ThoughtWorks, 2006 MSL Progress

© ThoughtWorks, 2006 Reporting Bug Status

© ThoughtWorks, 2006 VSTS and CruiseControl Limitations of TFS build process Regular check-ins of code Build early build often CC.Net plug-in for TFS Source Control

© ThoughtWorks, 2006 Build Reporting

© ThoughtWorks, 2006 Next steps Currently beta-testing internally Add detail reports and filtering Addition of source code metrics – E.g. cyclomatic complexity, ratio test vs. production code, class and method sizes Release on CodePlex once beta-testing complete