The TW Agile template for VSTS

1. The TW Agile template for VSTS Microsoft Architect Insight Conference – 2007 Nick Hines ThoughtWorks

2. 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

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

4. 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.

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

6. Process Guidance

7. 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.

8. 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

9. 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.

10. 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”

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

12. 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

13. 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

14. 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.

15. Story Card from VSTS

16. The Master Story List (MSL)

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

18. 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

19. 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)

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

21. 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

22. Issue Log

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

24. 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

25. Project Velocity

26. Yesterday’s weather

27. MSL Progress

28. Reporting Bug Status

29. 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

30. Build Reporting

31. 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