Agile Project Delivery Using Scrum
1
Training Goals
• Understand Scrum at a high level
• Understand the basic principles and practices of Scrum
• Appreciate how scrum processes can help teams practice selfdirected leadership
• Understand that our learning will be iterative
2
Think “out-of-the-box”
• Scrum is founded on sound industry accepted project
management practices
• Open our mind to new concepts.
3
Agile & Scrum Overview
Document Title Goes Here
4
All Agile frameworks share a common
philosophy
• The Agile Manifesto
Individuals and Interactions
Working Software/Product
Customer Collaboration
Responding to Change
• www.agilemanifesto.org
5
Business + Information Solutions
What is Scrum?
Scrum is an iterative framework for developing any product or
managing any work.
• Iterative and incremental
– Project progresses in series of short iterations
– Product increment delivered at end of each iteration
• Self organizing & cross-functional team
– Direction provided primarily at beginning and end of each iteration
– Team works collectively to plan and organize their work
• Very collaborative
– Makes everything highly visible through constant communication
and collaboration.
7
Scrum Flow
8
Scrum Components
• Major components of Scrum
• Release
– Completion of a major
component of work.
– Consists of multiple iterations
– Release Preparation occurs
at the beginning of a release
• Iteration
– Time box (10-20 days)
– Completion of a small
increment of work
– Multiple iterations in a
release
9
Project Team
Product Advisor
(Faculty/TA
Coach)
End Users
Iteration
Master
Dr. Quicksall &
“Sampling Team”
Scrum Team
10
Roles – Product Advisor (aka Product Owner)
• Coaching Responsibilities
– Trains and Mentors the Scrum team
– Guides the Iteration Master to follow and maintain the process
(Faculty/TA Coach)
• Defines the features of the product
– What Stakeholders want
– What goes into the product
• Decides on the release dates and content
• Responsibilities
– Prioritizes the user stories in the Product Backlog
– Ultimate decision maker on requirements issues
– Negotiates Acceptance Criteria for work results
11
Roles – Iteration Master (aka Scrum Master)
• Member of the Scrum team
• Facilitator, not manager
• Keeps the process moving
– “Enforces” the Scrum framework(w/help of coaches)
– Ensures full-team involvement in all meetings
– Keeps everything visible
• Advocate for improved practices
• Communicate impediments and successes
• Tracks and communicates progress of team
12
Roles – Scrum Team
•
•
•
•
•
Cross functional, self organizing and self managing
Self motivated to help the team succeed
Works to solve problems & produce product increments
Follows Scrum practices and organizational policies
Innovative
– Looks for ways to design, build, document with less effort
– Looks for ways to create a better product
– Adds new ideas or issues discovered to the Product Backlog
• Stays focused on the iteration goals and commitments
13
Self-Directed Teams
• Responsible for planning, managing and executing work
– Team plans work together
– Team determines approach for completing work
– Each person volunteers for tasks. Tasks are not assigned.
• Works together to meet goals
–
–
–
–
Step up to help team members succeed
No “not my job”
Provide solutions and feedback
Abide by team decisions
• Responsible for team success or failure
14
Scrum
Release Preparation
Document Title Goes Here
15
Release Preparation
• Visioning – Team collaborates to establish the
detailed project vision and understand the
expected outcomes of the project.
• Roadmapping - Map out the long term plan for
how the product will evolve over time and
establish optimal release windows
• User Story Workshop – Create, estimate, and
prioritize user stories for the project
• Release Planning – Review the Product Backlog
to plan the release timeline and iteration planning
activities
16
Visioning
• Overview
– Initial meeting with the Scrum team to review from a business
perspective, collaborate, and agree on the…
• … goals, value, vision for completing the project
• … scope, stakeholders, architecture impacts, and tool requirements.
– Opportunity to agree on the team working agreement
• Outcomes
– Team alignment on project scope and expectations
– Team Working agreement
– Initial Issues and Risks
17
Vision Statement
Team collaborates to establish the project vision and understand the
expected outcomes of the project.
Some team choose to create a vision statement:
For research scientists who would like to remotely access a well,
sample the water, and test it on site, the Quicksall.org initiative
will provide researchers a robot that can self-navigate a variety
of terrains, sample from various well types, and perform on-site
testing and remediation
18
Roadmapping
• Overview
– Opportunity to create a Product Roadmap
• Shows how the product and architecture may evolve to deliver desired features
and benefits to specific user or customer groups.
– Determine high level milestones that could affect the project.
• Can include product release dates, infrastructure upgrades, important customer
milestones or any other significant date that could impact the project.
– Determine any dependencies between milestones, architecture, and
features to be developed for customers
• Outcomes
– A long term view of the Product Roadmap with any dependencies
associated with customers, features, events, rhythms, and the
architecture.
19
Roadmapping – Simple template
• Recommendation of 5 rows labeled as indicated.
Add other rows as needed
• Low tech (sticky notes) good way to collaborate
3Q ‘12
4Q ‘12
Customer
Groups
HQ TM and
Selected Field
Features and
Benefits
SSO Web-based
Reporting
Architecture
and Systems
Xcelsius /
Weblogic /
Oracle
Release 1
2Q ‘13
3Q ‘13
Rel 2.2 Enabled
Master
Geography
Events and
Rhythms
Scheduling
1Q ‘13
ETL to SCW
Freeze May 6th
Freeze Aug 7
and Sept 7
Release 2
Release 2.2
Licensing
Release 3
20
Scrum
Release Preparation
User Story Workshop
Document Title Goes Here
21
User Story Workshop
• The User Story Workshop consists of 3 sections
– User Story Creation
• Project team creates user stories
– User Story Estimation
• Project team estimates the story points for each user story
– User Story Prioritization
• Product Advisor with input from the Scrum team places the user stories in
priority based on customer need and business value
22
User Story Creation
• Overview
– Initial opportunity for the team to review, discuss, and document
requirements for the project as user stories.
– In Scrum a requirement is documented as a user story which is placed in
the product backlog. It is the responsibility of the Product Advisor to
review, prioritize and approve all user stories placed in the product
backlog.
• Outcomes
– An initial set of user stories for the project
23
User Stories – Backlog
• Product Backlog
– List of all requirements in the form of user stories
– Prioritized by the Product Advisor
– Items can only be added or removed by the Product Advisor
• Iteration Backlog
– User stories chosen to be worked in this iteration
– Created by the team from the product backlog
– Highest priority product backlog items
Iteration
Backlog
Product
Backlog
24
User Stories - Key Features
• Key Features
– High-level features of the product being developed
– Defined in Visioning
– Used as a starting point to create user stories
Product
Feature A
User
Story 1
User
Story 2
Feature B
User
Story 3
User
Story 4
User
Story 5
25
User Stories – Quicksall.org Examples
Robot
Identify
Obstacles
Navigation
Flat Surface
Loose
Gravel
Uganda
Dadaab
Collect
Water
Sample
Ground
Level Well
High Well
26
User Stories – What are they?
• Easy to use and manage approach to writing requirements
• A short, plain-language description in terms of customer value
• Created during story-writing workshops at the beginning of the
project, and then augmented during the project
• Augmented by screen mock-ups, design diagrams or any other
artifact that enhances understanding of the story.
• Anyone can write a user story
27
User Stories – Why User Stories?
• Stories are easy to understand
– Developers and customers understand them
– People are better able to remember events if they are organized into
stories
• Stories are the right size for planning
• Support and encourage iterative development
– Can easily start with very large stories and epics then break down close to
development time
• Stories support flexible and efficient development
28
User Stories – Should follow INVEST
Independent
Avoid dependencies on other stories
Negotiable
Leave or imply some flexibility
Valuable
Identify value to the customers, not developers
Estimable
Enough detail to estimate.
Small
Must get done in a single iteration
Testable
Acceptance criteria should be identified
INVEST coined by Bill Wake
29
User Stories - Personas
• Personas
– A role identified that will use or interact with the developed product
– Can be the product itself or components of the product
– Can be real people or roles in an organization
30
User Stories - Format
• User Stories are comprised of 3 parts
•
•
•
As a/an <persona>
I want/I need <function>
So that <reason>
•
As an Unregistered User I want to be able to enter my name and contact
information so that I can create an account to become a registered user.
•
As an Administrator I need a report so that I can see who is a registered user
for my application.
•
As a Registered User I need to change my password so that my personal
information is secure.
•
As an Purchaser I want to create a wish list of books so that I can return to
purchase them at a later time.
31
User Stories – Quicksall.org Examples
• As Uganda Research Scientist I want a robot that can
autonomously maneuver from one location to another on a level
playing field so that I have the ability to get well samples from
Uganda.
• As Professor Quicksall I want a robot that can differentiate the
playing field boundary from the obstacle so that I can identify the
location of the wells.
• As Professor Quicksall I want a robot that can identify the obstacle
by reading a series of tape lines so that I can determine which well
has been encountered.
32
User Stories – Card Layout
33
User Stories - Confirmation
• Confirmation methods are written on the back of the card
– Include conditions of satisfaction or acceptance criteria
– Essentially test cases that address various scenarios and questions
34
User Stories – Spur Conversation
• The card only covers the most basic information
• The next level of detail comes in conversations between the Product
Advisor and the Scrum team
• The conversations take place
– At Project inception, during story writing sessions
– During the Iteration Planning Meeting
– During the iteration
35
Value Statement
Quicksall.org
User Story Creation
For research scientists who would like to remotely access a well,
sample the water, and test it on site, the Quicksall.org initiative will
provide researchers a robot that can self-navigate a variety of
terrains, sample from various well types, and perform on-site testing
and remediation
• Take 30 minutes to create user stories
Confirmation:
Dealer Add Books
As a Dealer I need a method to add the
title, author, year published, and price for
my books, so that users will be able to
search items.
· Verify books can be added
· Verify the book information includes: title, author,
year published, and a price
Personas
Quicksall.org reps
Research Scientists
Create others if needed
Notes:
36
Scrum
Release Preparation
User Story Estimation
Document Title Goes Here
37
User Story Estimation
• Overview
– User Story Estimation is the initial opportunity for the Product Advisor and
Scrum team to review and estimate the relative user story points for each
user story.
• Outcomes
– An initial set of estimated user stories
38
User Stories – Using Story Points
• User stories are estimated in user story points not time.
• Advantages to story points versus time estimates
– Estimating is very quick because it is an intuitive estimate
– The estimate indicates an item’s size relative to another, and does not
give the illusion of being precise.
– Estimating time can be hard, but we are all good at comparison.
39
User Stories – What is estimation?
• Notes on Story Points
– Scrum team does the estimation, not the Product Advisor
– An estimate of size, risk, and complexity – NOT TIME
– Relative sizing of items is the key
– Points cannot be transferred between teams
– Points are based on teams that are stable throughout the development
process
40
User Stories – Estimation “Planning Poker”
• Planning Poker
– Collaborative estimation method to help the team align on the relative size
and complexity of each user story
– uses multiple card decks each consisting of 8 cards numbered 1, 2, 3, 5,
8, 13, 20, and 40.
41
User Stories – “Planning Poker” Rules
• Iteration Master selects and reads the highest priority user story that
has not already been estimated
• Team briefly discusses the user story
• Scrum team members SIMULTANEOUSLY show their selected card
representing the story point estimate
– The high and low team members in turn discuss why they selected the
value they did (try to keep to less than 5 minutes for the total discussion)
– The Scrum team then re-votes based on the views presented
• The Iteration Master writes the value on the card and this becomes
the story point value
• Repeat the process for the next highest priority user story
42
Scrum
Release Preparation
User Story Prioritization
Document Title Goes Here
43
User Story Prioritization
• Overview
– Opportunity for the Product Advisor, with input from the Scrum team to
review and place the user stories into a prioritized order based on
business value and customer need.
• Outcomes
– A set of prioritized project user stories
44
User Stories - Prioritization
• User stories are prioritized by the Product Advisor with input from the
Scrum team.
• Highest priority user stories should be delivered during the earlier
iterations
• Prioritization methods
– Business Value
– Product Advisor opinion
– Technical Feasibility
– Internal voting
– Survey customers
45
Quicksall.org
Estimation & Prioritization
• Use the Antique Dealer ecommerce user stories already created
1. Take 20 minutes to estimate the story points for each
• Review the user stories created previously with the group
• Estimate the user stories using “Planning Poker” cards
2. Take 10 minutes to prioritize the created user stories
• Review the user stories previously estimated
• Product Advisor and Scrum team prioritize the user stories based on
what needs to be completed first or has the most business value.
• Place the user stories on the table in priority order
46
Scrum
Release Preparation
Release Planning
Document Title Goes Here
47
Release Planning
• Overview
– Establish a plan and goals that the team can understand and
communicate relative to the release of the project
– The release plan establishes the goal of the release, the major risks, the
features and functionality that the release will contain. It also establishes
a probable delivery date
• Outcomes
– A determination of the user stories required for a release
– The timing required for a release and functionality available
– Documented activities required to perform a release
48
Release Planning – Determine Iterations
• Scrum team determines how much work can be accomplished in
each iteration.
49
Scrum
Iteration Execution
Iteration Planning
Document Title Goes Here
50
Iteration Execution
• Overview
– Where the majority of work for the project gets completed
– Each task created for the iteration is selected by a team
member as a work function
– During this time that team member is responsible for working
toward completing that task
• Outcomes
– Working product, reviewed, and accepted by the Product
Advisor
– Team has reflected on the work and has a plan to improve
51
Iteration Sessions
• A iteration is a time-boxed iteration of development. Consists of:
– Iteration Planning
– Daily Standup Meeting
– Iteration Review Preparation
– Iteration Review
– Retrospective
• Iterations occur one after another
Day 1
Day 2
Day 3
Day 4
Day 5
Daily Standup
Daily Standup
Daily Standup
Daily Standup
Day 6
Day 7
Day 8
Day 9
Day 10
Daily Standup
Daily Standup
Daily Standup
Daily Standup
Iteration Review
Iteration Review
Preparation
Retrospective
Iteration Planning
52
Iteration Planning
• Overview
– Product Advisor
• Communicates the Iteration Goals
– Scrum Team
• Selects highest priority user stories from the product backlog
• Writes out the tasks needed to complete those user stories
• Estimates the number of hours each task will take to complete
• Agrees as a team to accept the user stories and work associated with the
iteration.
• Outcomes
– Scrum team agrees on work to be done in the iteration
53
Iteration Planning – Understand, Select,
Commit
• Understanding
– First half of Iteration Planning addresses all of the team’s questions
• Do they understand the items at the top of the prioritized Product Backlog
• Selecting
– Selecting user stories from the prioritized Product Backlog
– Discussion then moves to task breakdown, design, other implementation
issues before time box ends
– Scrum team associates an hourly estimate for each task
• Committing
– Team commits to the work selected
54
Iteration Planning – Creating Tasks
• For each user story selected the Scrum team creates the tasks to
complete the associated user story
• Tasks typically correspond to “standard” activities
– Designing a new database schema
– Coding / Building
– Updating documentation
– Testing
• Once the task is created an estimation of the number of hours
required to complete that task is written on the task card
55
Iteration Planning – Task Breakdown
• Tasks are written for each User Story
Product
Feature
A
Feature
B
User
Story 1
Task
User
Story 2
Task
Task
User
Story 3
Task
Task
Task
56
Iteration Planning – Commit to Iteration
Scrum Team:
• Assesses all the work that needs to be completed for the iteration
• Takes into consideration all tasks for the iteration
• Determines how much time each team member can devote to
completing tasks
• Adjusts user stories and associated tasks (add or remove), as
needed to match capacity of team
• Commits to completing all the work for the iteration.
57
Quicksall.org
Iteration Planning
• Use the user stories already created, estimated, prioritized
• Take 20 minutes to plan the first iteration
• Exercise Steps:
– Select a user story from the Product Backlog for Iteration 1
– Write out the tasks that are needed to complete the user story
– Estimate how many hours each task will take to complete
58
Scrum
Iteration Execution
Daily Standup
Document Title Goes Here
59
Daily Standup
• Overview
– Where the Scrum team meets to discuss
• How the iteration is progressing
• Any obstacles encountered since the last meeting
• Improve communications, eliminate other meetings, identify and remove
impediments, highlight and promote quick decision-making, and improve
everyone’s level of project knowledge
• Outcomes
– Updated tasks
– Updated iteration burn down chart
60
Daily Standup – an important 15 minutes
• Same time and location every day
• Exchange of information, not traditional reporting
• Focused on What, not Why or How
• Scrum team members answer 3 questions
– What did I do since the last Daily Scrum?
– What will I do before the next Daily Scrum?
– What is blocking me from being successful?
61
Iteration Burndown Chart
• How do we measure progress during an iteration?
Ideal Progress
Daily Progress
62
Scrum
Iteration Execution
Iteration Review
Document Title Goes Here
63
Iteration Review Preparation
• Overview
– The objective is to prepare for the Iteration Review meeting. At this
meeting all user stories selected for the current iteration are reviewed and
determined if they are completed and ready to be demonstrated to the
Product Advisor and Stakeholders
– Last event for the iteration with no additional work being performed
• Outcomes
– Team determines the agenda for the Iteration Review
– Team determines the logical order for discussing the completed user
stories during the Iteration Review
– Team decides who will demonstrate each user story. It’s a best practice
to have each team member present in the meeting
64
Iteration Review
• Overview
– Held at the end of each iteration.
– Informal meeting to demonstrate completed functionality
– The Scrum team and Product Advisor collaborate about what was
completed during the iteration and what to do next.
– Product Advisor decision on the next steps for the project: Continue, Stop,
or Release
• Outcomes
– A review of all user stories selected for the iteration
– Feedback and acceptance/rejection of user stories by Product Advisor
– Updated user stories and/or action items
65
Iteration Review – “Quicksall’s” Decision
• Product Advisor determines what direction the project should take
based on the demonstrated user stories, and input from the team and
stakeholders.
– CONTINUE
• Continue current Product Backlog
• Add user stories and reprioritize
– STOP
• Terminate the project
– RELEASE
• Sufficient functionality has been demonstrated to contain value for the
stakeholders such that the product can be released in the demonstrated state
66
Scrum
Iteration Execution
Retrospective
Document Title Goes Here
67
Retrospective
• Overview
– An opportunity for the team to look back on the last iteration with the
intention of learning from their experience and applying this learning to
future iterations
– A facilitator encourages the Team to reflect and inspect how the last
iteration went in regards to people, relationships, process, and tools.
– Identify actionable improvement measures that can be implemented in the
next iteration by the team
• Outcomes
– Action items for improving the effectiveness of the team and the process
68
Retrospective – When? Why? What?
• When?
– After every iteration to handle mid-course adjustments, gather metrics,
and improve
• Why?
– Reflection on the process
– Collect feedback during the life of the project
– Focus is on what we can learn from what happened
• What?
– Topics can include anything associated with success of project; people,
relationships, process, tools, iterations, etc.
69
Retrospective – Action Plans
• Once all the information is collected for each of the questions the
facilitator walks the team through the comments
• The team reviews the comments and determines an Action Plan for
improvement
Stop
-~~~~~~~
-~~~~~~~
-~~~~~~~
-~~~~~~~
-~~~~~~~
-~~~~~~~
-~~~~~~~
Start
-~~~~~~~
-~~~~~~~
-~~~~~~~
-~~~~~~~
-~~~~~~~
-~~~~~~~
-~~~~~~~
Continue
-~~~~~~~
-~~~~~~~
-~~~~~~~
-~~~~~~~
-~~~~~~~
-~~~~~~~
-~~~~~~~
Action Plan
-~~~~~~~
-~~~~~~~
-~~~~~~~
-~~~~~~~
-~~~~~~~
-~~~~~~~
-~~~~~~~
70
Start your Scrum Project – Ready, Set, …
Planning
Release
Execution
71