AGILEACTIVIST.

COM

by Paul Klipp,
the Agile Activist

A Quick Guide to Scrum

and why is it right for me?
By Paul Klipp

1
AGILEACTIVIST www.paulklipp.com
A Quick Guide to Scrum
and why is it right for me?

Creative Commons
Attribution-Noncommercial-Share Alike 3.0 Unported

You are free:

to Share — to copy, distribute and transmit the work

to Remix — to adapt the work

Under the following conditions:

Attribution. You must attribute the work in the manner

specified by the author or licensor (but not in any way that
suggests that they endorse you or your use of the work).

 
Noncommercial. You may not use this work for commercial
purposes.

Share Alike. If you alter, transform, or build upon this work,

you may distribute the resulting work only under the same or
similar license to this one.

For any reuse or distribution, you must make clear to others the
license terms of this work. The best way to do this is with a link to this
web page.
Any of the above conditions can be waived if you get permission from
the copyright holder.
Nothing in this license impairs or restricts the author's moral rights.

Attribution should be to Paul Klipp and include a link to

http://www.paulklipp.com

2
AGILEACTIVIST www.paulklipp.com
A Quick Guide to Scrum
and why is it right for me?
By Paul Klipp

An Explanation of Scrum
A classic, and in my opinion flawed, software development approach is to define
all functional requirements up front and then deliver an all-inclusive release. Requirements
changes can mean additional development, documentation and approval time, thus delaying
the entire release. What’s more, studies show that many initial requirements prove to be of no
value to users and just create additional development and maintenance costs. A contrasting
approach is a development methodology known as Scrum. Scrum recognizes the changing
nature of requirements and adapts elegantly to them. By delivering working software in small
pieces, it allows users to start interacting with the software and to provide valuable feedback
that radically improves the quality of the final product.
 
Scrum is actually a rugby term that refers to the heads-down formation of players around
the ball. In terms of software development, Scrum falls under the rapid product deployment
methodology known as “agile” development, which also includes Lean Development and
Extreme Programming. Scrum breaks requirements into subsets that are the focus of short
development iterations which produce deployable, functioning subsets of the overall end result.
The first iterations deliver software that the business can use immediately upon deployment.
Thus, the business begins to realize ROI relatively quickly and continues to do so
incrementally, rather than at the entire project’s end. An added benefit occurs in that
requirements changes, which tend to occur as the business reviews deliverables, can be made to
planned iterations without hindering the iteration currently being delivered.
This guide is a brief introduction to how the Scrum methodology works to produce
higher-quality software faster and more efficiently.
Scrum is not limited to software development, however. I’ve just advised a local
philanthropist who wants to organize groups of volunteers from around the world to erect
statues of Wojtek the bear (that’s another story) in several countries including Poland, Iran,
and Israel to use Scrum to organize the effort. This is simply a common sense approach to
identifying goals, setting priorities, organizing work, measuring progress, and keeping a team
focused and on track regardless of the type of project.
 

3
AGILEACTIVIST www.paulklipp.com
A Quick Guide to Scrum
and why is it right for me?
My Experience with Scrum
Before discovering scrum, I had spent years managing projects using the standard PMI-
based waterfall approach (to be fair, PMI has now embraced agile methods and so PMI and
agile are not necessarily mutually-exclusive). I "successfully" managed teams from 2 to 250
people in this manner. I put successfully in quotes, because although I always managed to
deliver, I wasn't happy much of the time, nor were the programmers, testers, or clients. It's
funny, actually, how we managed to create great software, mostly on time and budget, and yet
the process was so often characterized by stress, uncertainty, unproductive meetings, awkward
negotiations, late nights in the office, and crisis management. When I started my own software
company, I could do things my own way. With new employees and new clients, the only
remnant of my past as a project manager was me. I'd read about extreme programming and
scrum and I set about to make my future brighter than my past by changing the way I worked.
The results were amazing. Five years later, I can say that I've never had a project fail, never
missed a deadline, never had an upset client, and only asked my team to work overtime twice
to get releases out (I wish I could say it had never happened, but two weekends in five years is
still not bad). Scrum made all the difference. For one thing, everyone knows what's happening
all the time and shares the same realistic expectation. So even when things go wrong, as they
are bound to from time to time in software, everyone including the client knows quickly and
works together to solve problems rather than getting frustrated with uncertainty and searching
for someone to blame. Frequent, quality communication, short iterations with solid
deliverables, and a process that accommodates change elegantly without the need for change
orders and renegotiating deadlines and budgets removes all the frustration, stress, and most of
the risk from building great software.
 

4
AGILEACTIVIST www.paulklipp.com
A Quick Guide to Scrum
and why is it right for me?
The Players
 Scrum Roles – Pigs and Chickens

Traditional project roles don’t exist in the Scrum environment. The team leader, unlike a
project manager, does not assign tasks or interact with the business users.  The business
product owner writes the requirements – not someone from the development team. The team
as a group shares responsibility for the entire end result, making the individual team member
less likely to isolate until finished coding his or her “piece” of the project.  Scrum roles are
humorously categorized as either Pigs or Chickens.
 
The Pigs
The Pigs are those held accountable for successful, on-time project completion and
include the product owner, Scrum team members and the ScrumMaster.  (“Their bacon is on
the line!”) 

 Product Owner
The product owner represents the users and is responsible for compiling, prioritizing and
changing user requirements. In the case of outsourced development, this is usually the client
or a representative of the client.
 
Scrum Team
A Scrum team contains no more than nine members and consists of hands-on workers
such as developers, quality assurance testers and designers. Team members and business users
directly interact during the development effort. The fact that they share joint responsibility for
the overall project encourages intra-team communication and collaboration.
 
ScrumMaster
The ScrumMaster is the Scrum team guide. It is the ScrumMaster’s responsibility to
remove project impediments and to avoid micro-management. The ScrumMaster also ensures
that Scrum practices are followed and that everyone involved is communicating effectively. He
or she helps the team to implement best practices and to incorporate into their process the
lessons of past experience.

The Chickens
The Chickens include stakeholders such as end users and managers who are affected by
but are not responsible for the end result. These are all the people interested in the project,
whether they are users, marketers, product managers, or financiers. They do not play an active
role in the scrum process because too many decision-makers (meaning more than one) really
introduces a lot of confusion into a process, but they are very welcome to follow the team’s
progress by listening in on the daily scrum meetings, reviewing the progress via the backlogs
and burndown charts, and using the product of each iteration and providing feedback to the
Product Owner.

5
AGILEACTIVIST www.paulklipp.com
A Quick Guide to Scrum
and why is it right for me?
The Scrum Process
Describing Customer Requirements (User Stories)

The customer is responsible for

communicating the desired end results. Sample User Story
This is done by creating use cases and/or
New User Registration
“user stories.” A user story is a short, one
to three sentence description of a desired
As a Visitor, I can register to become a
behavior and may be written by a project
user of the application so that I can
manager, an end user, a product owner or
access the features that are only
another stakeholder. My preferred format available to registered users.
for a user story is borrowed from Mike
Cohn and it is “A user role is able
to accomplish some task in order to address some need.” The product owner compiles and
prioritizes the user stories into a list which is called the product backlog. The product backlog
is a living document that is edited constantly as priorities change or new ideas evolve.
 
Creating Iterations (Sprints)

The Scrum team, ScrumMaster and product owner meet to break the product backlog
into subsets of effort known as iterations or Sprints.  An iteration is logically identified based
on developer time estimates and product owner prioritization and is further subdivided into
detailed tasks collectively known as the Sprint backlog. Each iteration should be of short
duration (e.g. two to four weeks), should deliver functionality that the business can use right
away, and should be approved by the product owner. Prior to approving an iteration, the
product owner should verify that the user stories for the iteration sufficiently describe what
needs to be done. Once approved, an iteration is “timeboxed”, which means that its user
stories and duration are fixed in stone and the iteration will produce tested, deployment-ready
software on time, every time.
 

6
AGILEACTIVIST www.paulklipp.com
A Quick Guide to Scrum
and why is it right for me?
The Iteration/Sprint Process

Task Selection

Scrum team members select the individual tasks on which they want to work, based on the
priority given to the story by the product owner. Highest business value stories are done first. 

Collaboration

Frequent communication among the developers is encouraged and helps to generate a

better end result. Ongoing direct interaction between developers and end users minimizes
surprises and drastically shortens the feedback loop, increasing efficiency.

User Story Testing

Right after a user story is completed, it is acceptance tested. Test results are immediately
made available to the product owner.

Daily Scrum Meetings

Throughout the iteration, the ScrumMaster organizes brief (5 - 15 minute), daily team
meetings to share accomplishments and reveal any progress impediments. In the daily scrum,
via telephone or Skype, every team member will briefly answer three questions:

1.        “What have you done since the last scrum?”

2.        “What do you intend to do before the next scrum?”
3.        “What do you need to do your job as effectively as possible?”

7
AGILEACTIVIST www.paulklipp.com
A Quick Guide to Scrum
and why is it right for me?
After the scrum meeting, it is the ScrumMaster's job to work with the product owner to
remove any impediments to optimal team performance, which could include such things as
getting feedback on a new feature, an answer to a question, or obtaining some hardware or
software that will improve a team member's performance.

Sprint Evaluation

The Scrum team may meet with the ScrumMaster and product owner to demonstrate the
deliverable at the end of each iteration. Additionally or alternatively, the product owner and
business users may evaluate the deliverable outside of the Scrum team’s presence. It is up to
the product owner to declare when the business value realized by an iteration is sufficient to
merit deployment. The product owner is responsible for updating the product backlog and is
free to alter subsequent Sprint requirements.
 
Sprint Review/Retrospective

At the end of an iteration (Sprint), the Scrum team meets to discuss lessons learned and
makes concrete changes to ensure that future sprints are even more effective. This process of
continual, gradual improvement is a sustainable way to achieve spectacular results over time.
 
Modify and Repeat

The process of defining, approving, implementing and deploying each iteration is

repeated until the product backlog has been completed or the product owner decides that
enough business value has been delivered to declare the project a success. In my experience, it
is not at all uncommon for a product owner to declare success with 20-30% of the initial
backlog items still remaining. These are the items that a tradition development process would
include, but which through an iterative and adaptive process, the business owner and end
users realize are not really as valuable as they thought at the beginning. The result is higher-
quality, lower-cost software delivered faster. 
 

8
AGILEACTIVIST www.paulklipp.com
A Quick Guide to Scrum
and why is it right for me?
Glossary
Agile Software Development – set of software development methodologies including
Lean Development, Extreme Programming and Scrum, designed for rapid deployment and
change accommodation

Iteration – Subset of the software development effort producing a deliverable that can
be deployed and used by the business (also known as a Sprint)

Product Backlog – a high-level list of “user stories” ( and/or use cases) explaining the
functionality that the users require

Product Owner – a business unit representative who compiles, maintains and prioritizes
user requirements for a given product development effort

Scrum – an agile development methodology for project definition and execution

ScrumMaster – the person responsible for ensuring that scrum practices are being
followed and for working with the product owner to remove any impediments to optimal team
effectiveness.

Scrum Team – a team with no more than nine members directly involved in a given
product development effort

Sprint – Subset of the software development effort producing a deliverable that can be
deployed and used by the business (also known as iteration)

Sprint Backlog – the set of detailed tasks that comprise a Sprint

Daily Scrum – A daily meeting, timeboxed to fifteen minutes, in which every member of
the scrum team appraises the others of their progress and needs by answering the three scrum
questions. Any discussion is tabled for after the scrum meeting.

Increment – A piece of deployable code that is produced at the end of iteration. It

represents real business value in the form of completed and fully tested and approved features.

Self-managing Team – refers to a team that takes responsibility for the quality and
completeness of their work and than chooses the route to success that works best for them, as
opposed to a "team" of individuals each only interested in their own assigned tasks. A self-
managing team is more motivated, generally happier, and more efficient.

9
AGILEACTIVIST www.paulklipp.com
A Quick Guide to Scrum
and why is it right for me?
Story Points – A relative unit of measure of the complexity of a user story or task. A
team assigns story points to user stories during the planning game and these points are
mapped to time based on the team's historic velocity.
Velocity - a measure of the average number of story points completed per iteration over
time, using a burndown chart.

Burndown chart - A line graph with time on the X axis and story points remaining on
the Y axis. Displayed boldly on the team's wall, it clearly communicates at a glance the status
of the iteration

Ideal Days – Sometimes a team will estimate tasks in ideal days, which is defined as a
solid day's work with no distractions or interference. These don't really exist, but real days can
be calculated based on the team's velocity.

Retrospective – A meeting held at the end of every iteration in which the Scrum team
identifies what went well and poorly during an iteration and chooses practices to continue or
to modify to make future iterations more successful

User Story – A short statement that describes a feature in terms of what a user is able to
accomplish with the software

Use Case – A more structured description of a feature that also includes how the
software will respond to different success and failure situations

Planning Game – The meeting in which the entire scrum team reviews all of the stories
for the sprint backlog, identifies tasks, clarifies initial details with the Product Owner, and
estimates the stories

Themes – A group of related stories. Examples of themes might be "user management"

and "payment processing". Themes are a good way to organize stories, especially during the
initial release planning

Roles – these define the users of the application. They may be as simple as "registered
user" and "system administrator" but I often like more descriptive roles, such as "blog owner",
"blog contributor", "blog visitor", "blog commentator" which better define how a user is using
the software.

Timeboxed - means that a set duration is non-negotiable. A timeboxed meeting might

last only 15 minutes, not a second more, and so all participants are motivated to maximize
efficiency. A timeboxed iteration means that when the deadline is reached, there will be no
excuses. Code must be finished, checked in, tested, approved, and ready to deploy live.
Timeboxed iterations make planning easier for stakeholders because they know the promises
they make to users will be kept.
 

10
AGILEACTIVIST www.paulklipp.com
A Quick Guide to Scrum
and why is it right for me?

Need
 
Help?
I have helped teams around the world improve their performance
through agile methodologies. Whether you need advice,
training, or coaching, I can get your team on the road to
success with Scrum.  I am also available to speak on a variety
of topics related to software creation and off shoring.
 

Website: www.paulklipp.com

Email:   paul@paulklipp.com

Skype: paulklipp
 

Further Reading

Agile Estimating and Planning by Mike Cohn

Agile Project Management with Scrum by Ken Schwaber
Agile Retrospectives by Esther Derby and Diana Larsen
Scrum and XP from the Trenches by Henrik Kniberg
 

11