1

Agile Project Delivery Using Scrum

2

Training Goals

• Understand Scrum at a high level• Understand the basic principles and practices of Scrum• Appreciate how scrum processes can help teams practice self-

directed leadership• Understand that our learning will be iterative

3

Think “out-of-the-box”• Scrum is founded on sound industry accepted project

management practices• Open our mind to new concepts.

Document Title Goes Here 4

Agile & Scrum Overview

5

All Agile frameworks share a common philosophy• The Agile Manifesto

• www.agilemanifesto.org

Individuals and Interactions

Working Software/Product

Customer Collaboration

Responding to Change

7

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.

8

Scrum Flow

9

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

10

Product Advisor(Faculty/TA

Coach)

Project Team

Dr. Quicksall & “Sampling Team”

End Users

Scrum Team

Iteration Master

11

Roles – Product Advisor (aka Product Owner)

• Coaching Responsibilities– Trains and Mentors the Scrum team– Guides the Iteration Master to follow and maintain the process

• 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

(Faculty/TA Coach)

12

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

13

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

14

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

Document Title Goes Here 15

Scrum

Release Preparation

16

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

17

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

18

Vision Statement

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

Team collaborates to establish the project vision and understand the expected outcomes of the project.

19

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.

20

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 1Q ‘13 2Q ‘13 3Q ‘13

Customer Groups

Features and Benefits

Architecture and Systems

Events and Rhythms

Scheduling

HQ TM and Selected Field

SSO Web-based Reporting

Xcelsius / Weblogic / Oracle

Release 1 Release 2

Freeze May 6th Freeze Aug 7 and Sept 7

Master Geography

ETL to SCW Licensing

Rel 2.2 Enabled

Release 2.2 Release 3

Document Title Goes Here 21

Scrum

Release PreparationUser Story Workshop

22

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

23

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

24

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

ProductBacklog

IterationBacklog

25

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

26

User Stories – Quicksall.org Examples

Robot

Navigation

Flat Surface Loose Gravel

Identify Obstacles

Uganda Dadaab

Collect Water

Sample

Ground Level Well High Well

27

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

28

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

29

User Stories – Should follow INVEST

Avoid dependencies on other stories

Leave or imply some flexibility

Identify value to the customers, not developers

Enough detail to estimate.

Must get done in a single iteration

Acceptance criteria should be identified

INVEST coined by Bill Wake

Independent

Negotiable

Valuable

Estimable

Small

Testable

30

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

31

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.

32

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.

33

User Stories – Card Layout

34

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

35

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

36

Quicksall.orgUser Story Creation

• Take 30 minutes to create user stories

Valu

e S

tate

men

t 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

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.

Dealer Add Books · Verify books can be added· Verify the book information includes: title, author,

year published, and a price

Notes:

Confirmation:

Personas Quicksall.org reps Research

Scientists

Create others if needed

Document Title Goes Here 37

Scrum

Release PreparationUser Story Estimation

38

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

39

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.

40

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

3 5813 20 2 401

41

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.

42

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

Document Title Goes Here 43

Scrum

Release PreparationUser Story Prioritization

44

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

45

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

46

Quicksall.orgEstimation & 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

Document Title Goes Here 47

Scrum

Release PreparationRelease Planning

48

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

49

Release Planning – Determine Iterations• Scrum team determines how much work can be accomplished in

each iteration.

Document Title Goes Here 50

Scrum

Iteration ExecutionIteration Planning

51

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

52

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 5Iteration Planning Daily Standup Daily Standup Daily Standup Daily Standup

Day 6 Day 7 Day 8 Day 9 Day 10Daily Standup Daily Standup Daily Standup Daily Standup

Iteration Review Preparation

Iteration Review

Retrospective

53

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

54

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

55

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

56

Iteration Planning – Task Breakdown• Tasks are written for each User Story

Product

Feature A

User Story 1

Task Task

User Story 2

Task Task

Feature B

User Story 3

Task Task

57

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.

58

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

Document Title Goes Here 59

Scrum

Iteration ExecutionDaily Standup

60

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

61

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?

62

Iteration Burndown Chart• How do we measure progress during an iteration?

Ideal Progress

Daily Progress

Document Title Goes Here 63

Scrum

Iteration ExecutionIteration Review

64

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

65

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

66

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

Document Title Goes Here 67

Scrum

Iteration ExecutionRetrospective

68

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

69

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.

70

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

Action Plan- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~

Start- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~

Continue- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~- ~ ~ ~ ~ ~ ~ ~

71

Start your Scrum Project – Ready, Set, …

Planning Release

GO!