Scrum Summarized

If you like the contents of this e‐book, you may buy the printed book from:

http://www.pothi.com/pothi/book/sachin‐mehra‐scrum‐summarized

Scrum
SUMMARIZED

Sachin Mehra, PMP

© Sachin Mehra

All rights reserved. No parts of this publication may be
reproduced, stored in a retrieval system, or transmitted, in any
form or by any means, electronic, mechanical, photocopying,
recording, or otherwise, without the prior permission of the
author.
mail2smehra@gmail.com
http://www.linkedin.com/in/sachinmehra

To

My family, my forever love.

Contents at a Glance

Preface ...............................................................................................x
About the Author ........................................................................... xiii
.
Introduction ...................................................................................... 1
Birth of “Scrum”................................................................................ 5
Scrum ................................................................................................ 9
Agile Manifesto ............................................................................... 11
Principles behind the Agile Manifesto ............................................ 13
Scrum Alliance ................................................................................ 15
Roles in Scrum (entities involved) .................................................. 17
Getting started ............................................................................... 23
Where to go from here ................................................................... 35
Recommended Readings ................................................................ 37
References ...................................................................................... 39

Preface

Thank you a lot for reading my book! My sincere aim is to get
you started on adopting and practicing Scrum as soon as
possible. This book is not the final step in your Scrum
education and journey, rather this may be your first one.

This book is written for anyone and everyone who wish to
understand and adopt Scrum. In this book, I have used my
experience and knowledge of Scrum to describe the key
concepts to get you started, where you go from here is upto
you to decide.

I wrote my first book titled “Project Communication
Management Summarized” in 2008, which took me almost
one year to complete and publish it. While I was writing it, I
realized that the TOC of my book keeps changing. I never got
satisfied with the content either. Every time I started writing
the content, I reviewed whatever I had done the last time
and made a list of changes I needed to make before looking
at the To‐Do list. I always had a big backlog of work to
accomplish, however the changes kept adding on to my To‐
Do list. By the time I completed the book, I had re‐written the
matter of that book several times. Now you can imagine
what I would have done with the TOC.

I had started with a list of To‐Dos (a backlog of things to be
done to complete and publish the book). Based on my time

availability, book’s needs and my priorities I created another
list of To‐Dos which was a slice out of the main list. I started
working on the list to complete the small task in hand, it was
always easier to work on and complete the small task in
hand. I changed my hat as per needs to act as reviewer,
writer and author of the book. My wife acted as a reviewer of
the final chapters/sections at the end of each slice of work. I
added suggested/required changes in the main To‐Do list,
which I prioritized to create the work slice (smaller list of
tasks To‐Do) with definitive schedules and then worked upon
the work slice. At the end of each day, I used to mark the
achievements (tasks completed) in the word doc I used as
work slice. In all, I completed my book by using 17 such slices
of work.

So what did I do all this while? I used Scrum to help me
complete and publish my book. Yes, this is what Scrum is,
well almost.

Over the past few years, I have come across many people
who believe that they practice Agile methodologies
(primarily Scrum and XP), and I would say that they are all
right in their own perspective.

I would like to express my gratitude to my present and past
employers, where I earned my knowledge and experience to
make this book possible.

Many people helped me directly and indirectly to make this
book a reality. My sincere thanks to all the people who

contributed to my thoughts and knowledge, and inspired me
to write this book.

My special thanks to Anand Rajan, my mentor, for his
guidance, insight, and common sense to project
management.

I’m happy to acknowledge that this book has profited greatly
from Vikas Hazrati’s experience and knowledge. I thank him
for reviewing content of this book in his personal time.

Finally, many thanks to Divya, my wife, for inspiring me and
proofreading this book.

Any comments about this book, or any inaccuracies that
might be present (which are entirely my responsibility), can
be sent to me at mail2smehra@gmail.com.

Sachin Mehra

About the Author

Sachin Mehra is a veteran engineering manager who is a
MBA and certified Project Management Professional (PMP).
In over 12 years of software development and management
experience, Sachin has worked for small start‐up to
established innovative companies.

He has vast experience in Program/Project Management,
Consulting, Business Analysis, Outsourcing and Off‐shoring,
Service transition and Management, Onsite Coordination,
Sales Support, Enterprise Architecture, Application Designing
and Development, Testing, Integration, and Implementation.

Post working hours, Sachin enjoys watching movies, reading,
writing, and spending time with his family.

Scrum Summarized – by Sachin Mehra

Introduction

The traditional way of software development which most
organizations use is called “Waterfall Model”. There are
many variants of this model, however some common
characteristic are big upfront requirements, comprehensive
documentation, contract negotiation, process oriented, and
planning everything before the work starts (plan the work
and work the plan approach).

We know that change is the only constant. Unfortunately,
while using waterfall model, most often, the best product
ideas, requirement changes, and feedback from customer
come at the end of the development cycle during user testing
(or worst, after production release), when changes are most
difficult and most expensive. Don’t get me wrong, I am not
saying that waterfall model does not work, it does and does
very well when applied to the right kind of projects.

The fact is software project development is not very
predictable. Failures occur and they hurt, very badly. The
customer relationships, team morel, and organizational
reputation get negatively impacted.

This is where agile methodologies (like Scrum) come to the
rescue. Agile approaches assume things change, and they do
change very frequently.

1


If you tell people where to go, but not how to get there,
you’ll be amazed at the results.

–General George S. Patton

2


Agile methodologies (like Scrum) are helpful and effective
when:

• Requirements are unclear or ever changing or are
not completely known at the start

• Working with tight schedules for delivery

• Working with new or innovative technology

This book will introduce you to the Agile software
development methodology ‐ Scrum. Scrum is a good method
of managing software development projects in an
environment where requirements are likely to change quickly
or are not completely known at the start of the project.

The following chapters will introduce you to Scrum and
related key concepts. They will enable you to jump start
using Scrum to be able to manage your projects better. You
will also be guided to other resources on the web and print
media to enrich your knowledge and broaden your horizon.

3


4


Birth of “Scrum”

Scrum gets its names from the world of the sport, rugby. It is
the name of the formal conglomeration of forwards who
bind together in specific positions to move forward towards
their goal.

Who coined this
term “Scrum”?

Let’s read on
to find out.

5


In 1986, Hirotaka Takeuchi and Ikujiro Nonaka described a
new holistic approach which increases speed and flexibility in
commercial new product development. They compare this
new holistic approach, in which the phases strongly overlap
and the whole process is performed by one cross‐functional
team across the different phases, to rugby, where the whole
team quot;tries to go to the distance as a unit, passing the ball
back and forthquot;.

In 1991, DeGrace and Stahl, in Wicked Problems, Righteous
Solutions referred to this approach as Scrum, a rugby term
mentioned in the article by Takeuchi and Nonaka.

In 1990s, Ken Schwaber used an approach that led to Scrum
at his company, Advanced Development Methods.

6


At the same time, Jeff Sutherland developed a similar
approach at Easel Corporation and was the first to call it
“Scrum”.

In 1995, Sutherland and Schwaber jointly presented a paper
describing Scrum at OOPSLA '95 in Austin, its first public
appearance. Schwaber and Sutherland collaborated during
the following years to merge the above writings, their
experiences, and industry best practices into what is now
known as Scrum. In 2001 Schwaber teamed up with Mike
Beedle to write up the method in the book quot;Agile Software
Development with SCRUMquot;.

Scrum is not an acronym, however the title of Schwaber and
Mike’s book confused many people, and still does.

So, SCRUM = Scrum?

Right.

7


8


Scrum

Scrum is an iterative incremental process of software
development.

Is that it?

Need a detailed
definition, read on.

As per Scrum Alliance website, Scrum is a lean approach to
software development. Scrum is an agile software
development framework. Work is structured in cycles of
work called sprints, iterations of work that are typically two
to four weeks in duration. During each sprint, teams pull
from a prioritized list of customer requirements, called user
stories, so that the features that are developed first are of

9


the highest value to the customer. At the end of each sprint,
a potentially shippable product is delivered.

As per Control Chaos website, Scrum is a variation on Sashimi,
an quot;all‐at‐oncequot; approach to software engineering. Both
Scrum and Sashimi are suited best to new product
development rather than extended development. Sashimi
originated with the Japanese and their experiences with the
Waterfall model. They had the same problems with the
Waterfall model as everybody else, so they adapted it to suit
their own style. Realizing that speed and flexibility are as
important as high quality and low cost they reduced the
number of phases to four ‐‐ requirements, design, prototype,
and acceptance ‐‐ without removing any activities, which
resulted in overlap of the Waterfall phases. Then they made
the four phases overlap. (Sashimi is a way of presenting
sliced raw fish where each slice rests partially on the slice
before it). Other companies took Sashimi one step further,
reducing the phases to one and calling it Scrum. (A scrum is a
team pack in Rugby, everybody in the pack acts together with
everyone else to move the ball down the field).

Scrum is based on Agile
methodology. Let’s find out what
is Agile manifesto.

10


Agile Manifesto

As per agilemanifesto.org, on February 11‐13, 2001, at The
Lodge at Snowbird ski resort in the Wasatch mountains of
Utah, seventeen people met to talk, ski, relax, and try to find
common ground and of course, to eat. What emerged was
the Agile Software Development Manifesto.

Manifesto states:

• 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.

11


12


Principles behind the Agile Manifesto

As per agilemanifesto.org, principles behind the Agile
Manifesto are:

1. Our highest priority is to satisfy the customer
through early and continuous delivery of valuable
software.

2. Welcome changing requirements, even late in
development. Agile processes harness change for the
customer's competitive advantage.

3. Deliver working software frequently, from a couple
of weeks to a couple of months, with a preference to
the shorter timescale.

4. Business people and developers must work together
daily throughout the project.

5. Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done.

6. The most efficient and effective method of conveying
information to and within a development team is
face‐to‐face conversation.

13


7. Working software is the primary measure of
progress.

8. Agile processes promote sustainable development.

9. The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

10. Continuous attention to technical excellence and
good design enhances agility.

11. Simplicity‐‐the art of maximizing the amount of work
not done‐‐is essential.

12. The best architectures, requirements, and designs
emerge from self‐organizing teams.

13. At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.

What is the relation
between Agile principles

and Scrum?

Scrum is a management

methodology for
implementing agile principles.

14


Scrum Alliance

The Scrum Alliance is a nonprofit organization committed to
delivering articles, resources, courses, and events that will
help Scrum users be successful.

Founded by Ken Schwaber, Mike Cohn, and Esther Derby, the
Scrum Alliance's mission is to promote increased awareness
and understanding of Scrum, provide resources to individuals
and organizations using Scrum, and support the iterative
improvement of the software development profession.

Visit
http://www.scrumalliance.org to
learn more about Scrum Alliance.

15


16


Roles in Scrum (entities involved)

Roles in Scrum are divided into two group, pigs and chickens,
based on a joke about a pig and a chicken in the book Agile
Project Management with Scrum that goes like:

A pig and a chicken are walking down a road. The chicken
looks at the pig and says, quot;Hey, why don't we open a
restaurant?quot; The pig looks back at the chicken and says,
quot;Good idea, what do you want to call it?quot; The chicken thinks
about it and says, quot;Why don't we call it 'Ham and Eggs'?quot; quot;I
don't think so,quot; says the pig, quot;I'd be committed but you'd only
be involved.quot;

So the division of roles is based on the commitment level of
the parties involved in project.

Pigs are committed –

Team, Product Owner, and
ScrumMaster

Everyone else is a chicken –
Stakeholders, Users, and
Managers

17


Let’s look into
details of each role.

Team – Is the team of people with cross‐
functional skills (analysis, architecting, designing, coding,
testing, etc) who does the actual work of creating the
required deliverables (potentially shippable product). Scrum
team is self‐organizing team, it takes its own decisions. For
example, they’ll give commitment for the work that can be
delivered and decide how to accomplish the commitments.

Primary responsibility of the team is to build potentially
shippable product at the end of every sprint. They may
contribute their inputs and ideas to the product owner about
how to make the product better and more useful.

It is suggested to have a team size of 5‐7 people. In case of a
large product, product should be divided into small logical
parts, each of the part may have its own team.

18


Product Owner – Is the customer representative
or internal team member who acts as the voice of the
customer and bridge the gap between Scrum team and the
customer. They ensure that the team is able to understand
the user stories (requirements) and have all the information
required to create the product from a business perspective.

Primarily responsible for:

• Writing user stories

• Adding user stories to the product backlog

• Prioritizing the stories for next sprint

• Reviewing (along with others) the product at the end
of each sprint

Usually, there is only one product owner. In case of a large
product, product should be divided into small logical parts,
each of the part may have its own product owner.

19


ScrumMaster – Is a facilitator for the team. He is
not a manager or leader of the team (Scrum team is self‐
organizing), hence this role may be performed by a team
member who may be 50% developer.

Primarily responsible for:

• Protecting the team from outside interference (like
change in scope of the sprint in progress)

• Ensuring that everyone understands and follows the
Scrum practices

• Conducting daily Scrum with the team

• Removes impediments to the ability of the team

• Conducting sprint retrospective meeting with the
team at the end of the sprint

Usually, there is only one ScrumMaster per team.

20


Stakeholder – Is anyone who has an interest in
the project. It may be an individual or organization that are
actively involved in the project, or whose interests may be
affected as a result of project execution or project
completion.

Primary responsibility of the stakeholders is to review the
sprint output and provide feedback.

User – Is someone who will be the end‐user of
the software product that is being created.

Manager – Is someone who will set up the
environment for the product development organization.

21


The secret of getting ahead is getting started. The secret of
getting started is breaking your complex overwhelming tasks
into small manageable tasks, and then starting on the first
one.

‐Mark Twain

22


Getting started

Create a Product Backlog – Product owner creates a list of all
the things that can be done by the team to create the
product, it is called Product Backlog. It may include the
required new functionality, modification in existing
functionality or bugs/issues in the functionality with broad
descriptions of each item.

Customers, User, etc provide requirements to product owner

Product owner creates the product backlog

23


# Description Rough
Estimate

1 Manage user 16

2 Send email on user creation 4

3 Manage store items 12

4 Search sales records 4

Sample Product Backlog

Product backlog is continuously updated by the product
owner to reflect the change in the need/choice/feedback/etc
of the customers.

Prioritize the product backlog – Product owner is responsible
for creating and maintaining this backlog. Product owner
prioritizes the list in the order of value delivered to the
customer. End result is highest value items at the top of the
list.

24


Alright, now that we have
the prioritized list of
items, what’s next?

Product owner will freeze the
top items so that we start
sprint planning.

Sprint Planning – First step to start a sprint is to have a sprint
planning meeting. ScrumMaster facilitate a meeting between
Product owner and team to discuss the goals and status of
the product backlog.

First step in the planning is to find out the total time that can
be used for the sprint. This time excludes time spent on work
breaks (lunch, coffee, etc) or time spent in meetings or doing
other organizational activities (if any).

25


For example:

• Each of my team member has 6hrs a day that can be
used for the sprint

• We are a 5 people team

• Our sprint is of 5 working days

Hence, I have total of (6 x 5 x 5) 150 sprint hours. This allows
us to accomplish 150hrs of work from the product backlog.

Second step is to start with the product backlog top items
(high priority and value items) one‐by‐one and break them
into smaller tasks. Any clarification required is discussed with
the product owner.

Items are broken down into hours with no task being more
than 16hrs. In case the task is longer than 16hrs, it is further
divided into smaller tasks until it is below 16hrs.

Team provides estimates and decides how much work they
will commit to complete. Nobody assigns the task, team
chooses it themselves.

This process of taking items from product backlog is
continued till all available sprint hours are consumed.

26


High priority and Break into smaller tasks
high value items

Sprint backlog
Product backlog – functionality which is
top items committed to be deliver

At the end of the sprint planning meeting, team will have a
list of tasks (with details) which they own and have
committed to deliver. This document is called Sprint backlog.
Only measurable/verifiable goals, which have to be attained
at the end of the sprint, are committed.

Sprint length: 1 week

Working days during the sprint: 5

# Task M T W T F

8 Setup new store 8 16 8 8 0

28 Create CSS 0 12 16 16 8

21 Add standard error codes 16 4 16 8 8

Sample Sprint Backlog

27


Sprint – Once the sprint planning meeting is over (should be
one day long), the sprint starts. Sprint is a period of time
when the team works on the sprint backlog to complete
what they have committed. Sprint is usually 2‐4 weeks long,
30 days if we go by the book.

ScrumMaster ensures that there is no additional request
added to the sprint backlog during the sprint and team is
able to focus on delivering what they committed.

Scrum team working one team room

Daily Scrum (standup meeting) – This is a team meeting
which happens at scheduled place every day at same time.
Anyone can attend this meeting, however only team is
allowed to speak. Duration of this meeting is 15 minutes (or
less) and everybody has to stand (that’s why it is also called a
standup meeting).

28


Team talks about three things:

1. Progress made since last meeting.

2. Tasks planned to be performed today.

3. Anything that prevents a team member from
performing work as efficiently as possible (this is
called Impediment is Scrum).

Only reporting happens during this meeting, no discussion is
held. ScrumMaster takes notes on impediments during the
meeting and works towards removing them after the
meeting, he may setup separate meetings to resolve
impediments that cannot be resolved during the meeting.

ScrumMaster discusses with stakeholder to resolves team impediments

ScrumMaster maintains the sprint backlog by updating task
status to reflect the latest status. It reflects the status of
tasks (is it done or not; if not done, how much time will it
take to complete). This helps the team understand the total
29


amount of time (efforts) required to complete their
committed work.

ScrumMaster plots this (decreasing) effort on the graph to
shows the progress made each day by the team. This chart is
called a sprint Burndown chart.

Burndown chart

Sprint review meeting – Once the sprint is over, team gives a
demo of the functioning software (potentially shippable
product) of the sprit to product owner, users, managers and
everyone else who has his interest vested in the product.

30


Reviewers can share their feedback and inputs during this
meeting, this feedback can be used for next sprint.

Retrospective meeting – It is a meeting of the team, product
owner and ScrumMaster which is held after the sprint review
meeting to understand what works (and what doesn’t). It
helps identify the areas of improvements for each of the
party in subsequent sprints.

During this meeting, common issues are further analyzed to
pin‐point the root cause and eliminate the issue in
subsequent sprints. The resultant actions (and their results in
next sprint) can be reviewed during the next retrospective
meeting.
How many sprints should
we do to release the
product?

Do as many sprints as you need
to complete what product owner
think is required to release the
product.

31


Release – After a few sprints, product owner takes a decision
to release the product to the users when he thinks the
product is complete, this is called a release.

Product release may be time or functionality driven. Market
conditions may also affect the release. In case of large
products, release meeting may be part of the first (or all)
sprint planning meetings to create a high level plan for the
product release.

32


Time to ship the product to the end users

At this point, another sprint may be required to do the final
integration and testing in preparation for the launch.

I got it all! Now, I can do
Scrum.

33


I have missed more than 9,000 shots in my career.

I have lost almost 300 games.

On 26 occasions I have been entrusted to take the game
winning shot, and I missed.

And I have failed over and over and over again in my life.

And that is precisely why I succeed.

‐ Michael Jordan

34


Where to go from here

In the preface of this book I had mentioned that you’ll have
to decide where you go from here. Again, this book is not the
final step of your Scrum journey, rather it may be your first
one.

There is no journey without initial problems. Your Scrum
journey is not going to be any different. You may face issues
and there will be times when you’ll feel that Scrum does not
work, my only suggestion is, don’t give‐up. Adapt your
processes to match your needs.

I suggest, you continue your journey at the recommended
readings section of this book and seriously consider taking
Scrum training/coaching.

All the best! Hope you
have a pleasant Scrum
journey.

35


36


Recommended Readings

1. Agile Software Development with SCRUM ‐ by Ken
Schwaber and Mike Beedle (Buy at Amazon ‐
http://www.amazon.com/Agile‐Software‐Development‐
Scrum/dp/0130676349)

2. Agile and Iterative Development: A Manager's Guide ‐ By
Craig Larman (Buy at Amazon ‐
http://www.amazon.com/Agile‐Iterative‐Development‐
Managers‐Software/dp/0131111558/ref=pd_sim_b_4)

3. Agile Software Development ‐ by Alistair Cockburn

4. Reference material at
http://www.scrumalliance.org/resources/

5. Reference material at http://www.controlchaos.com/

6. Agile estimating and planning – by Robert C Martin
37


38


References

1. http://agilemanifesto.org/

2. http://www.scrumalliance.org

3. http://en.wikipedia.org

4. http://www.controlchaos.com/

5. Agile Software Development with SCRUM ‐ by Ken
Schwaber and Mike Beedle

39


40

Scrum Summarized

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Scrum Summarized

Ähnlich wie Scrum Summarized (9)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Scrum Summarized