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

© ThoughtWorks, 2007

The TW Agile template for VSTS

Microsoft Architect Insight Conference – 2007

Nick Hines

ThoughtWorks


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


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.

Agile

XP Scrum Crystal

TW Agile

RUP


When to use TW Agile

Mor

e S

tric

t

More Agile

Wat

erfa

llW

ater

fall RUPRUP

XPXP

RADRAD

TWAgile

TWAgile

• TW Agile: Not as radical as XP, but incorporating many XP practices such as pair programming, TDD, Continuous Integration, etc.

ScrumScrum

CrystalClear

CrystalClear


Process Guidance


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.


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


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.


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”

Import Vehicle

Manually Create Vehicle

Import Pricing

Only attach ECR that was purchased by current seller of the vehicle. We should not attach an ECR from the previous seller

Auto Attach ECR from CO Auto Attach Vehicle Pictures

VIN Decoding

Match Prices to Inventory

IE. Add information that wasn’t imported and specific to OVE

Resolve Import Errors Supplement Vehicle Info

Relist

Delete Vehicle

Review Listing to be posted Turn Vehicle 'live'(post listing)

Preview Vehicle-Optional Turn Vehicle 'live' from preview View Vehicle status

Edit consist of lowering Floor or Buy Now Price ONLY

Edit Active Listing w/ Bids

End Sale

Sell Now

Respond to'make an offer'

Bidding is still open

Bidding is closed

Sell Now (reserve not met) Send conditional sale message

Buyer accepts counter offer

Respond to conditional sale message

Counter offer

Send purchase confirmation

Expire sale Relist

End auction

Fail to respond

End Sale

Conditional Sale Transaction Completes

Transaction completes

NO

OVE Dealer/Consigner – Sell Vehicle

Vehicles to list on ove.com

Match Prices to Inventory

Listing Remain in Inventory Delete Listing

Continue Sale

Edit complete listing

Accept Offer

YES

NO

YES

Edit Inactive Listing

Edit all fields

Edit Active Listing w/ Bids

Notify buyer that floor or buy now dropped.

Send confirmation to Seller about the change they made

Notification of change Continue Sale

Notify Bidder Auction Ended

Confirm Edit of Active Listing

Warn seller that by editing listing they will cancel all the current bids

NO

Notify bidder that listing has changed and their bid has been cancelled

Notify Bidder

YES

Edit all fields

Edit Live Auction with No Bids Continue Sale

Send Counter Offer Emails NO

YES

Admin will have the ability to unwind the deal if the buyer calls to say they do not want to purchase the vehicle (happens after user does not respond to email)

Unwind

Confirm that buyer wants to purchase the vehicle

Confirm Conditional Sale

New Expired

Available

Stopped

Add/Verify Mandatory data

Manually Activate Listing

Go Live Met? Pending

No

No

Sold

Auction expires

Preview

Expired

Yes

Live Sale?

Yes

Has Bids?

Yes

Has Bids

Yes

Reserve Met?No

No

Unbuy

Stopped

Unbid?

Yes

No

Buy Now

Make Offer

Offer accepted?

Conditional Sale

Sell Now

Yes

No

Reserve Met?

Yes

Sale accepted?

No

Yes

Expired

No

Yes

End sale

Live (No Bids)

Listing State Change Diagram


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


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


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


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.


Story Card from VSTS


The Master Story List (MSL)


Story Lifecycle

NewNew

Signed-offSigned-off

QA Complete

QA Complete

Dev Complete

Dev Complete

AnalysisComplete

AnalysisComplete

DefinedDefined

Add title, description, priority

and estimate

Add Acceptance Criteria and other

required information

Develop storyTest developed

code/functionality

Business review


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


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)


Risk Management Cycle

RISKDISCOVERY

Risk Management Cycle

EXPOSUREANALYSIS

CONTINGENCY PLANNING

RISK MITIGATION

ON-GOING TRANSITION MONITORING

DEPLOY COUNTER

MEASURES

Brainstorm & triage

Probability, Cost & Impact

Countermeasures & TriggersExecute mitigating

actions

Continue to monitor risk

Execute contingency


Capturing Issues in VSTS

Identifier for issue

State of issue: - initially Open

Priority of issue – Low, Medium, HighTextual description of issue

Actions to be taken to mitigate issue


Issue Log


Capturing Bugs in VSTS

Title of Bug

Story that bug relates to

State of bug – initially Open

Priority of bug- High, Medium, LowNumber of build in which bug detected

Estimated effort to resolve bug

Actual effort required to resolve bugBuild in which bug is resolved

Detailed description of bug

Detailed steps to recreate bug


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


Project Velocity

Velocity

0

5

10

15

20

25

30

35

40

45

50

i4.1 i4.2 i4.3 i4.4 i4.5 i4.6 i4.7 i4.8 i4.9 i4.10 i4.11 i4.12 i4.13 i4.14

Iteration

Ideal D

ays

Planned MSL Velocity Story Velocity (QA Passed) Story Velocity (DEV Complete)


Yesterday’s weather

Story progress from yesterdays weather(Predictions based on last 4 weeks)

0

200

400

600

800

1000

1200

13/02/2006

20/02/2006

27/02/2006

06/03/2006

13/03/2006

20/03/2006

27/03/2006

03/04/2006

10/04/2006

17/04/2006

24/04/2006

01/05/2006

08/05/2006

15/05/2006

22/05/2006

29/05/2006

05/06/2006

12/06/2006

19/06/2006

26/06/2006

03/07/2006

10/07/2006

17/07/2006

24/07/2006

31/07/2006

07/08/2006

14/08/2006

21/08/2006

28/08/2006

04/09/2006

11/09/2006

18/09/2006

25/09/2006

02/10/2006

09/10/2006

16/10/2006

23/10/2006

30/10/2006

06/11/2006

13/11/2006

20/11/2006

27/11/2006

04/12/2006

11/12/2006

18/12/2006

25/12/2006

01/01/2007

08/01/2007

15/01/2007

22/01/2007D

EV

Est

imat

e

Signed Off QA Complete Development Complete Analysis CompleteDefined Predicted to complete Predicted remaining


MSL Progress

MSL Progress(Based on QA-Passed)

0

200

400

600

800

1000

1200

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

Idea

l Day

s

MSL Planned MSL Velocity Story Velocity


Reporting Bug Status

High Priority Bug Status

0

20

40

60

80

100

120

140

160

180

200

i4.1 i4.2 i4.3 i4.4 i4.5 i4.6 i4.7 i4.8 i4.9 i4.10 i4.11 i4.12 i4.13 i4.14 Buff UAT UAT UAT UAT

Nu

mb

er o

f b

ug

s

Found Closed Backlog


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


Build Reporting


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

Documents

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