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
−Visual Studio ALM−Scrum−Planning a project−Planning a sprint−Running a sprint−Reporting
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
−Visual Studio ALM−Scrum−Planning a project−Planning a sprint−Running a sprint−Reporting
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
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
−Visual Studio ALM−Scrum−Planning a project−Planning a sprint−Running a sprint−Reporting
Product BacklogUser Stories
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!
DEMO
Agenda
−Visual Studio ALM−Scrum−Planning a project−Planning a sprint−Running a sprint−Reporting
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
Product BacklogUser Stories User Stories Tasks
(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
Product BacklogUser Stories User Stories Tasks
(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
Product BacklogUser Stories User Stories Tasks
(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”
Product BacklogUser Stories User Stories Tasks
(hours)
Iteration Backlog
Product BacklogUser Stories User Stories Tasks
(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
Product BacklogUser Stories User Stories Tasks
(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
Product BacklogUser Stories User Stories Tasks
(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
Product BacklogUser Stories User Stories Tasks
(hours)
Iteration Backlog
Running a Sprint
The backlog is prioritized and
ready for the team to plan the next
sprint
Product BacklogUser Stories User Stories Tasks
(hours)
Iteration Backlog
Agenda
−Visual Studio ALM−Scrum−Planning a project−Planning a sprint−Running a sprint−Reporting
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
DEMO
Resources
−Brian Harry−http://blogs.msdn.com/bharry−Aaron Bjork
−http://blogs.msdn.com/aaronbjork/