scrum and visual studio 2010

Succeeding with Agile Software Development with Scrum

Patrick Yong, MVP (SharePoint Server)http://patrickyong.net | [email protected]

Agenda

−Visual Studio ALM−Scrum−Planning a project−Planning a sprint−Running a sprint−Reporting

Visual Studio ALM

−Plan and Track−Design−Develop−Build−Test−Deploy

Plan and Track

Launching a new project

Choose process

template

Create a Team

project

Modify Area and Iteration

Tracking work Collaborate Process

GuidanceStay

Notified

DEMOCreating a new Team Project

Agenda


What is Scrum?

Roles

−Product owner−Scrum Master−Team role

Meetings

Meeting Purpose Duration Frequency

Sprint Planning Meeting

Determine what work to do in the coming sprint.

Two hours per week in the sprint, up to four hours

Once per sprint

Daily Scrum MeetingAllow team members to commit, collaborate, and communicate risks.

Fifteen minutes Daily

Sprint Review Meeting

Show the customer and other stakeholders the work that the team accomplished in the sprint, and receive feedback.

Two hours per week in the sprint, up to four hours

Once per sprint

Retrospective Meeting

Identify and implement ideas for process improvement.

Three hours Once per sprint

TFS Artifacts for Agile Development

−Work Items and Workflow−Queries−Dashboard−Excel Reports−Workbooks−Reports

Why Scrum?−Iterative Development

−Lots of small “product releases” over the project’s lifetime

−As opposed to one major product release at the end

−Bugs / Problems are found early−Products are usable earlier in the process−Involves the customer during each iteration

−Iterative Development lends itself to the Scrum modus operandi−Scrum’s artifact promote customer involvement −They allow the customer to re-prioritise the order

in which “development” work is done

A word of Warning

Some project managers might not like the following slides.

Viewer discretion is advised.

Managing Iterative Development Using Scrum

Waterfall vs. Iterative Development

requirement gathering

analysis & design

development

testing

deployment

time

cost of

change

Customer happy, early release?

80% of a product’s value comes from 20% of its features

Why focus on Iterative Development?

−Traditional, Waterfall profit & loss cost curve

Why focus on Iterative Development?

−Iterative Development, early release profit & loss cost curve

Agenda


Planning the Project“As a new customer I

want to register online so I can use the services offered”

Stories are listed on the backlog in priority order

New stories are added to the product

backlog

The team estimates each story using story

points

5

8

3

5

8

1

Prio

rity

Product BacklogUser Stories


Planning the Project

3

3

3

4

4

4

Sprint 3

The product owner re-prioritizes the backlogSprint 4

Stories are planned for completion in upcoming sprints

Prio

rity

Planning Product Backlog

What makes a good user story?

−INVEST −Independent−Negotiable−Valuable−Estimable−Small−Testable

−http://www.userstories.com/book

Start writing user story

−Does your user stories answer the following?−Who the user is?−What the user need to do?−Why the user need to do that?

−“As a <user>, I need to <action> in order to <reason>”.

Before you rank user stories

−Small enough to be implemented in the sprint

−Just detailed enough to describe and estimate the work that is required to implement the story

−Acceptance criteria defined

Epic and Theme

−Epic −Very large user stories that represent

a significant amount of work−Theme

−User stories that are fairly large, generally larger than you would implement in a sprint

−It must be broken down into smaller user stories.

Spikes

−Work that is not a direct implementation of a user story. −Research−Bug−Process improvements

Prioritize your user stories

−First Things First: Prioritizing Requirements−http://www.processimpact.com/

articles/prioritizing.html

Story Points

−Story points are a unit of measure for expressing the overall size of a user story

−Do not translate directly into a specific number of hours

−Less precise = less effort to determine−Do detailed estimation of hours of

work later

Velocity

−Total story points in a sprint−A starting point that you can use to

determine how many user stories to implement in the sprint.

Estimate Release Plan−Remember this:

−Each sprint, your team will complete an increment of the product that it could ship

−As such−Identify groups of user stories that, together,

provide enough business value to release−Determine in which sprints the team expects to

complete those groups of user stories−Note: Its OK to remove/ add user

stories to sprint

DEMOProject planning with MS Excel

Agenda



Planning a Sprint

User Stories Tasks (hours)

Iteration Backlog

Commit!

Commit!

3

3

3

Can’t Commi

t!

The team breaks down

each story into tasks

The team thinks this story

is more work than they can commit to…

Based on estimates the team commits to each story

During the sprint planning meeting, the product owner and the team add User Stories

to the sprint

Product BacklogUser Stories User Stories Tasks

(hours)

Iteration Backlog

Planning a Sprint

User Stories Tasks (hours)

3

3

3

3

Commit!

The larger story is removed from the

sprint and the team considers a smaller story on

the backlog

? Commit!

Commit!

The team can commit to this smaller story

The sprint is now planned and the team is ready to get

started!

Agenda


How do you Run a Sprint?− Track Progress

− Daily Sprint Meeting− What work has been completed− What work remains

− Deliver a “potentially shippable” increment

− Demo the value delivered− Retrospective


(hours)

Iteration Backlog

Running a Sprint

The team starts work on the

tasks…

Running a Sprint

2/1 2/4 2/72/10

2/132/16

2/192/22

2/252/28

020406080

100Remaining CompletedCompleted work

is reported daily


(hours)

Iteration Backlog

Running a Sprint

2/1 2/4 2/72/10

2/132/16

2/192/22

2/252/28

020406080

100Remaining Completed


(hours)

Iteration Backlog

2/1 2/4 2/72/10

2/132/16

2/192/22

2/252/28

020406080

100Remaining Completed

Running a Sprint

Each User Story has

been implemented

All work for the sprint is “done-

done”


(hours)

Iteration Backlog


(hours)

Iteration Backlog

Running a Sprint

The team holds a demo to show the value they have

delivered

And the team has developed a “potentially shippable” increment

Running a Sprint

The latest increment is shipped to customers


(hours)

Iteration Backlog

Running a Sprint

The team holds a retrospective…

Stories delivered in the last sprint are

closed

Stories and tasks are cleared from the

backlog – the team delivered on its

commitment


(hours)

Iteration Backlog

What worked? What didn’t work? What can the team

do to improve?

Running a Sprint

New Stories are added to the

Product Backlog


(hours)

Iteration Backlog

Running a Sprint

The backlog is prioritized and

ready for the team to plan the next

sprint


(hours)

Iteration Backlog

Agenda


Burndown and Burn Rate

Build Quality Indicator

Test Plan Progress

− Unhealthy symptoms− High no. of test failed− No. of passed test remained flat

Bug Status

Bug Trend

−Healthy trend−Bugs discovered early−Fewer bugs towards

the end−Bugs resolved faster than

being discovered

Stories Overview Report

Story Progress Report

Resources

−Brian Harry−http://blogs.msdn.com/bharry−Aaron Bjork

−http://blogs.msdn.com/aaronbjork/

scrum and visual studio 2010

Technology