Scrum Process

The Scrum Process John A. Lewis Chief Software Architect Unicon, Inc. 29 July 2010 © Copyright Unicon, Inc., 2010. Some rights reserved. This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/us/

Method vs. Methodology
Admittedly, this is a pet peeve:
Method : A means or manner of procedure, especially a regular and systematic way of accomplishing something
Methodology : A body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry; a set of working methods; The study or theoretical analysis of such working methods
Scrum (and other such things) are methods – not methodologies

Agile Software Development

Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more .
From the “Manifesto for Agile Software Development” See http://agilemanifesto.org/

Principles of Agile Development
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Principles of Agile Development (cont)
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity—the art of maximizing the amount of work not done—is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Nature of A Complete Method
There are two critical aspects of a software development method:
Process : How the project is conducted and coordinated. Provides for project management and control mechanisms. Not specific to software development.
Practice : How the developers perform software development. A set of practices and conventions that all developers follow in order to collaborative effectively and produce high-quality results quickly.

The Scrum Process

Scrum Process
Scrum is an Agile Process for running Software Development Projects.
Uses an Empirical Process control model instead of a Defined Process control model.
This means it depends on “Inspect and Adapt” cycles, instead of phases, hand-offs, sign-offs, and blame.
These cycles require regular inspections of the process, and constant adaptations to steer the direction of the process based on those inspections.
Scrum is made up of two cycles:
The Monthly Scrum Sprint (“the Sprint”)
The Daily Scrum Meeting (“the Scrum”)
All activity takes place within these two cycles.

Scrum Process Flow

The Scrum Sprint
Monthly cycle that results in a potentially shippable increment of the software product.
During this period the team is empowered to do whatever it takes to meet their goal.
Sprint length actually variable. Anything from 1-6 weeks is fine – adapt to pace of project.
Must develop an initial Product Backlog before beginning the first Sprint.

Product Backlog
Prioritized list of all features and changes that have yet to be made to the system.
High-level and loosely defined. Doable by one person in one Sprint.
Scrum Master is the owner and the ultimate arbiter of what's on the list and the priorities.
Before the first Sprint, the Scrum Master and the Scrum Team produce an initial Backlog.

Sprint Planning Meeting
Initial step for each Sprint.
Attended by the Scrum Master, the Scrum Team, and any other parties that want to see how the next Sprint will likely go.
1 st half of the meeting (~ 4 hours):
Scrum Team and the Scrum Master select items from Product Backlog that can be implemented in the next monthly Sprint.
Scrum Team and the Scrum Master agree on a Sprint Goal.
2 nd half of the meeting (~ 12-20 hours):
The Scrum Team creates the Sprint Backlog.

Sprint Goal
Each Sprint has a specific and stated goal.
Simple statement of what the Scrum Team will accomplish during the Sprint. Not more that a few sentences.
Capture the spirit of where the product will be at the end of the Sprint.
Used to measure the general level of success during the Sprint Review.

Sprint Backlog
Scrum Team takes the Product Backlog items for the Sprint and distills them into items for the Sprint Backlog.
Sprint Backlog items are lower-level and much more defined – measured in hours, not days – estimated from 1 - 16 hours or so.
Preferably managed in an Issue Tracking system (e.g. JIRA).
During a Sprint, if entirely new tasks are discovered, they can be added to the Sprint Backlog.
If a new task is not related to the Sprint Goal, then it is tossed back into the Product Backlog, to be prioritized by the Scrum Master.

The Daily Scrum Meeting
Within the Sprint, the Scrum Team gathers in the same place at the same time each work day.
Provides daily chance to “Inspect and Adapt”.
The Scrum Master asks each person, in turn:
"What have you done since the last Scrum meeting?"
"What do you plan to do before the next Scrum meeting?"
"What impediments are in your way?"
After the Daily Scrum, the team gets to work and the Scrum Master sets about removing impediments.

The Scrum Team
The Team consists of 5-9 people who will develop the product.
During each Sprint, the Scrum Team has two requirements:
Attend the Daily Scrum.
Update the Sprint Backlog.
The important metric on the Sprint Backlog is the estimated work remaining, not the work already done.
A task that had 3 hours remaining on Monday may have 5 hours remaining on Tuesday and 10 hours remaining on Wednesday, even though the developer has worked on it solid for 2 days. This is normal!

Burndown Chart
Need fully estimated Spring Backlog updated daily
Scrum Master can produce daily Burndown Chart
Shows trend towards timely completion of the Sprint Backlog

Pigs and Chickens
A not-so-funny joke:
A chicken and a pig decide to start a restaurant. The pig says, "What should we call it?“ The chicken says, "How about 'Ham & Eggs'?“ The pig says, "No thanks. I'd be committed, but you'd just be involved!"
People on the Scrum Team are Pigs (committed) – everyone else is a Chicken (involved).
At the Daily Scrum, only Pigs can talk. Chickens can come to the meeting to observe and learn, but they cannot:
Talk.
Make funny faces.
Whisper.
Take notes loudly.
Communicate in any way.
If they do, they must leave.
If they persist, they will be banned from the meeting.

Sprint Review
When the Sprint is complete, the Sprint Team conducts a demonstration of what was completed. No more than 2 hours of preparation are allowed.
This should be purely a functioning demo – no use of PowerPoint (unless you are developing PowerPoint itself!) or other slides / mockups.
The entire Sprint Team and the Scrum Master should attend. Others who are interested in seeing the results of the Sprint may also attend. Customer attendance is highly desirable.
Purpose is to solicit feedback. Observations and comments will commonly become items on the Product Backlog.

Complexity Points
Abstract estimations for Product Backlog
Also sometime called “Story Points” since its an estimate for each User Story
Assign points to each item to indicate relative complexity
Use Fibonacci numbers: 1, 2, 3, 5, 8, 13, 21
Add up all the complexity points for the Sprint gives you a measure of the scope

Planning Poker
Process for team Complexity Point estimates
Use set of playing cards with the various CP numbers – give each team member a set
Discuss the Backlog item and then each pick a card and lay down at the same time
Look for consensus or discuss further for more clarity and then repeat estimate
Avoids “groupthink” by having everyone give their own estimate simultaneously, rather than in sequence

Scrum Team Velocity
After each Sprint, measure the number of Complexity Points the team completed
Averaging these over several Sprints will give the Team Velocity
This allows for fairly accurate predictions of the rate at which the team can complete the remaining Product Backlog items that have CP estimates

Adopting the Scrum Process
The Scrum Process can be rolled out quickly with new projects via some simple training (i.e. these slides + supporting material).
The Scrum Master and Tech Leads will need additional training and coaching as the project progresses.
Good to have at least one or two people on the team who have done Scrum before, or have access to people who have done it before to ask questions.

Resources
Website: http://www.scrumalliance.org/
Book: "Agile Software Development With Scrum" by Ken Schwaber
Blog: Implementing Scrum by Mike Vizdos
Mailing List: Scrum Development Yahoo! Group
Planning Poker: http://www.planningpoker.com/

Questions & Answers John A. Lewis Chief Software Architect Unicon, Inc. [email_address] www.unicon.net

Scrum Process

by John Lewis on Aug 18, 2009

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 2

Statistics

Scrum Process Presentation Transcript