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. [email protected]

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 [email protected].

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

1

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.


2

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

–General George S. Patton


3

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.


4


5

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.


6

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 "tries to go to the distance as a unit, passing the ball back and forth".

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.


7

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 "Agile Software Development with SCRUM".

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

So, SCRUM = Scrum?

Right.


8


9

Scrum

Scrum is an iterative incremental process of software development.

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

Is that it?

Need a detailed definition, read on.


10

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 "all‐at‐once" 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.


11

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.


12


13

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.


14

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.


15

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.


16


17

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, "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says, "Good idea, what do you want to call it?" The chicken thinks about it and says, "Why don't we call it 'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed but you'd only be involved."

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


18

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.

Let’s look into details of each role.


19

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.


20

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.


21

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.


22

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


23

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


24

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


25

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

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.


26

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.


27

High priority and high value items

Break into smaller tasks

Sprint backlog – functionality which is committed to be deliver

Product backlog top items

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


28

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


29

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


30

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.


31

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.


32

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.


33

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.


34

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


35

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.


36


37

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


38


39

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


40

Scrum Summarized

Technology

Transcript of Scrum Summarized