CodeProject: What is SCRUM?. Free source code and programming help

Report Article

Discuss

Send to a friend

26 votes for this Article.

Popularity: 5.29 Rating: 3.74 out of 5

Introduction
SCRUM Values
The SCRUM Process
The Scrum Team
- The leader (SCRUM Master)
Commonly Used Terms
Key Players/Authors:
Resources

Introduction

SCRUM is a loose set of guidelines that govern the development process of a product, from its design stages to its completion. It aims to cure some common failures of the typical development process, such as:

Chaos due to changing requirements - the real or perceived requirements of a project usually change drastically from the time the product is designed to when it is released. Under most product development methods, all design is done at the beginning of the project, and then no changes are allowed for or made when the requirements change.
Unrealistic estimates of time, cost, and quality of the product - the project management and the developers tend to underestimate how much time and resources a project will take, and how much functionality can be produced within those constraints. In actuality, this usually cannot be accurately predicted at the beginning of the development cycle.
Developers are forced to lie about how the project is progressing - When management underestimates the time and cost needed to reach a certain level of quality, the developers must either lie about how much progress has been made on the product, or face the indignation of the management.

SCRUM has been successfully employed by hundreds of different companies in many different fields, with outstanding results.

You will find many similarities between SCRUM and Extreme Programming, but one of the major differences is that SCRUM is a fairly general set of guidelines that govern the development process of a product. For this reason, it is often used as a "wrapper" for other methodologies, such as XP or CMM (Capability Maturity Model) - that is, it is used to guide the overall process of development when using these other methodologies.

SCRUM Values

The SCRUM values are derived from the Agile values of software development.

Individuals and interactions over processes and tools - processes and tools are helpful, but they will do you no good if the team does not communicate and collaborate in a constructive fashion.
Working software over comprehensive documentation - documentation is important, but what's most important is to have working software.
Customer collaboration over contract negotiation - you are not just looking to get a contract and get money that way - you are solving the customer's problem.
Responding to change over following a plan - if the requirements or perceived requirements changed, so should the plans and design.

The SCRUM Process

Figure 1: General SCRUM Process

The scrum process has 3 main phases.

Planning

In this phase, the project is planned and high-level design decisions are made.

Sprint Cycle

Figure 2: The SCRUM Sprint Cycle

The sprint cycle is an iterative cycle of about 3-4 weeks, in which the actual development of the product is done. It starts out with a Sprint Planning Meeting to decide what will be done in the current sprint. Then the development is done. A sprint is closed with a Sprint Review Meeting where the progress made in the last sprint is demonstrated, the sprint is reviewed, and adjustments are made to the project as necessary.

The sprint cycle is repeated until the product's development is complete. The product is complete when the variables of time, quality, competition, and cost are at a balance.

Develop the product further - implement, test, and document.
Wrap up the work - get it ready to be evaluated and integrated.
Review the work done in this sprint.
Adjust for any changes in requirements or plans.

Closure

In this phase, the product's development is brought to a close, and the product is released.

The Scrum Team

The SCRUM team consists of 2 groups - the interested team, which consists of people who are interested, but who will not be doing the work, and the working team - people who are interested, and will be doing the work on the project.

A team typically has no more than 6-9 working members, although SCRUM has been successfully used with more members. If there are more members than manageable, the project should be broken into multiple sub-projects, each focusing on one, self-contained area of work (one for QA, one for documentation, etc.). There should be people to act as bridges - that is, to attend the meetings of more than one SCRUM team, and act as a communication bridge between the teams. Members of teams that are closely related/involved with each other should sit in on the other teams' SCRUM meetings.

The leader (SCRUM Master)

The team's leader is called the Scrum Master. He should be one of the members of the working team - that is, he should be one of the people who is actually doing the work on the project. The SCRUM Master measures progress, removes impediments, and leads the team meetings.

Commonly Used Terms

Sprint

The product is developed in a series of 1-to-4-week iterations, or sprints. Before a sprint is begun, a Sprint Planning Meeting is held to determine what features are to be implemented in that sprint. The sprint has 4 major steps:

Develop the product further - implement, test, and document.
Wrap up the work - get it ready to be evaluated and integrated.
Review the work done in this sprint.
Adjust for any changes in requirements or plans.

Product Backlog

A prioritized list of all the desired changes to the product being developed, put together by the product owner. See Figure 2.

Sprint BackLog

A list with items that will be completed in the current sprint, taken from the product backlog. See Figure 2.

Daily SCRUM Meeting

A 15-minute SCRUM meeting is held every day. The SCRUM Master asks the three questions, and all members of the team and interested parties take part and give feedback. The meeting should be held at the same place every time, so that people know where to go.

Unit Testing

A unit test is an automated test that ensures that the functionality required for a certain area of a project is implemented, and that there are no breaking changes that have not been taken into consideration. See http://www.xprogramming.com/software.htm for a list of unit testing frameworks for different languages/platforms.

Impediment

Impediments are things that get in the way of the progress of the project. The SCRUM Master is responsible to look for and remove these obstacles so that they do not slow down or impair the project.

3 Questions

The Scrum Master asks the developers 3 important questions at every SCRUM meeting:

What have you accomplished since the last meeting?
Are there any obstacles in the way of meeting your goal?
What will you accomplish before the next meeting?

Product Owner

The person who commissions the project, and defines the requirements and priorities for the product.

Sprint Planning Meeting

A meeting at the beginning of a sprint where the sprint is planned. Items from the Product Backlog are selected to be completed in the sprint, based on the priorities set by the Product Owner.

Sprint Review Meeting

A sprint is closed with a Sprint Review Meeting where the progress made in the last sprint is demonstrated, the sprint is reviewed, and adjustments are made to the project as necessary.

Key Players/Authors:

Jeff Sutherland is one of the originators of SCRUM, and was one of the first people to apply SCRUM to a real-life project.

Ken Schwaber is one of the originators of SCRUM.

Mike Beedle has successfully used SCRUM in numerous large-scale projects, and, together with Ken Schwaber, wrote the book Agile Software Development with SCRUM.

Resources

Sites

ControlChaos

SCRUM tutorial, XP with SCRUM, case studies, SCRUM certification
http://www.controlchaos.com/

SCRUM Alliance

Part of the Agile Alliance site family, and has a large article base on SCRUM.
http://www.scrumalliance.org/

Mountain Goat Software's SCRUM section

A good introduction to SCRUM.
http://www.mountaingoatsoftware.com/scrum/

Articles

The SCRUM Development Process

A detailed and definitive paper on SCRUM.
http://www.jeffsutherland.com/oopsla/schwapub.pdf

Introducing an Agile Process

Covers the issues involved with introducing an agile methodology to a development team or company.
http://www.mountaingoatsoftware.com/articles/IntroducingAnAgileProcess.pdf

Comparing RUP, XP, and SCRUM: Mixing a Process Cocktail for Your Team

Compares different agile methodologies, and helps you determine what methodology or mix of methodologies is right for your team.
http://www.netobjectives.com/events/download/rup_xp_scrum_pc_030326_ppt.pdf

Books

Agile Software Development With SCRUM

A close look at SCRUM, with numerous case studies. A must-read for managers and developers alike.

Agile Software Development Ecosystems

A look at various Agile software development systems, including SCRUM. Numerous case studies, and interviews with some of the leaders in the Agile development arena.

SCRUM In Practice

The Upside of Downsizing

A case study on a situation where SCRUM helped to make a development project a success even though the development company was downsizing.
http://www.mountaingoatsoftware.com/articles/UpsideOfDownsizing.pdf

Does Agility Work?

Some stories of success with SCRUM
http://www.sdmagazine.com/documents/s=7147/sdm0206a/sdm0206a.htm

Agile Meetings

This is an article on agile meetings, with a large section on how agile meetings helped real-life teams to prevent problems by communicating with each other.
http://www.intp.us/risingl1/articles/STQE.pdf

Tools

XProgramming Unit Testing Downloads Section

Links to downloads of unit testing software for most common languages.
http://www.xprogramming.com/software.htm

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Authors

Marc Clifton

Mvp, Protector, Supporter

Marc is the creator of two open source projets, MyXaml, a declarative (XML) instantiation engine and the Advanced Unit Testing framework, and Interacx, a commercial n-tier RAD application suite. Visit his website, www.marcclifton.com, where you will find many of his articles.

Marc lives in Hudson, NY with his son Ian, who attends the Hawthorne Valley School and he his in love with a goddess named Lynette. To contact Marc, email him at marc.clifton@gmail.com.

Occupation:	Architect
Company:	Interacx
Location:	United States

J. Dunlap

My main goal as a developer is to improve the way software is designed, and how it interacts with the user. I like designing software best, but I also like coding and documentation. I especially like to work with user interfaces and graphics.

I have extensive knowledge of the .NET Framework, and like to delve into its internals. I specialize in working with VG.net and MyXaml. I also like to work with ASP.NET, AJAX, and DHTML (it's nice except when inconsistencies and bugs make me want to tear my hair out!).

I am currently looking for contract work. My resume and contact info can be found here.

Occupation:	Web Developer
Location:	United States

Other popular Design and Architecture articles:

NHibernate Best Practices with ASP.NET, 1.2nd Ed.
This article describes best practices for leveraging the benefits of NHibernate 1.2, ASP.NET, generics and unit testing together.
Exception Handling Best Practices in .NET
Design guidelines for exception handling in .NET which will help you to create more robust software
Design Patterns Implementation in a Storage Explorer Application
A design patterns approach for designing and explaining a Storage Explorer application. The application is used to explore file composition in a computer storage.
Applying Robustness Analysis on the Model–View–Controller (MVC) Architecture in ASP.NET Framework, using UML
This article will enhance your vision on the usage of Robustness Analysis in conjunction with Model View Controller, using UML with application in ASP.NET. This article is a sequel to my articles on Architecture and Design with ASP.NET.
The Razor Framework :: Part 1 :: Plugins/Extensibility
An extensible dependency based plugin framework for .NET Applications.

Article Top

You must Sign In to use this message board.

Msgs 1 to 17 of 17 (Total in Forum: 17) (Refresh)

FirstPrevNext

Subject

Author

Date

Wondering how to address the issue of quoting larger projects?

Scott. L.

3:24 21 Jan '06

Hi there,
I work in a small IT company. We have taken on some larger projects recently and have had trouble doing accurate quotes on these larger projects. We have had 3 main programmers working in different locations (from home), and found that just didn't work as there was no collaboration. So in doing some research I came across your article here on SCRUM and it sounds like just what we need. So we have convinced all team members to work from the one location. Now we just need to work out how to quote more accurately, on the larger projects, which we have found difficult mainly because we are doing things we have never done before, using new technologies etc.

SCRUM seems to deal with the pace of development and effective use of team knowledge, but can you offer any suggestions on how to quote more accurately.

Thank you for your time,

Scott.

Re: Wondering how to address the issue of quoting larger projects?

Marc Clifton

3:34 21 Jan '06

Scott. L. wrote:
but can you offer any suggestions on how to quote more accurately.

If I knew that, I'd make millions on a book and as a consultant helping people do just that.

As a consultant, I usually just charge an hourly rate. Still, the companies want some sort of an estimate, and what I do then, even with small projects (because small projects can sound small but be really difficult) is to break the project up into milestones, and sometimes the milestones are very small (one week increments, in some cases). It's pretty safe to be able to estimate the first few steps of a project when I break it down into milestones, and it gets increasingly fuzzier as I go down the timeline.

What I do therefore is give my customers a firm estimate on the initial two or three milestones and then require a joint review of the work, reviewing what has been accomplished, what new information has been added to the knowledge about the project, a review of whether any course changes are needed based on new information, and of course, firmer estimates on the next two or three milestones.

I've found my clients really like this approach because it gives them the feeling (quite rightly) that they are involved in the development process and the decision making process, they feel they are more in control of their budget (which they are), they can see progress being made, and the iterative review cycle always (and I emphasize always) results in undiscovered but vital knowledge being suddenly discovered--business rules, workflow, real world requirements vs. someone's idea of how it should work, so on.

If a client doesn't want to work that way with me, then I don't want to work with them, because the result will most likely be terrible.

So, what I would suggest is, it's not an issue of more accurate quotes, but rather how you work with your customer to succeed in delivering what the customer really needs.

Marc

Pensieve

Re: Wondering how to address the issue of quoting larger projects?

Scott. L.

3:51 21 Jan '06

Mark,
Thank you for the reply. What you say is the way to go from a development point of view definitely. But generally we find clients won't commit to a project unless they get a "ball park figure", eg, it won't go over $X amount of dollars. Otherwise their perception is the project can go on indefinitely and never stop costing them money. Therefore they can not work out if the investment will be worth return, when the investment is unknown.

Thanks again for your thoughts mate.

Much appreciated.

Scott.

Re: Wondering how to address the issue of quoting larger projects?

Marc Clifton

3:56 21 Jan '06

Scott. L. wrote:
clients won't commit to a project unless they get a "ball park figure",

Good point. To get a ballpark figure, there are a variety (but I don't use them, so I don't have any links, sorry) of estimating tools out there. What they do is, given the requirements (screen, controls on the each screen, tables, fields in each table, and so forth) they estimate the complexity of the project (and therefore the manpower and cost) based on "industry standard" historical data. This includes testing, documentation, design, so forth.

One of my clients paid $10,000 for a company to work up such an estimate. The result was interesting, but what we all realized was, the resulting estimate was high by a factor of 10 because it couldn't consider the automation tools we were using.

But it's a baseline, which is really all the customer wants. You can adjust it based on your own in house expertise and tools.

Marc

Pensieve

Re: Wondering how to address the issue of quoting larger projects?

Scott. L.

4:14 21 Jan '06

Marc, Once again thank you for your thoughts. It is great to hear how others are tackling these issues. I will be sharing your insights with our team. Thanks for your time matey. Scott.
Sign In·View Thread·PermaLink

No question

Robert Goldwein

2:37 26 Aug '03

...just thanks for all these articles about design and I hope it's not the last one Robert
Sign In·View Thread·PermaLink

Re: No question

Marc Clifton

2:50 26 Aug '03

Thanks Robert, There should be several more, on Feature Driven Development, Crystal Light, and DSDM (Dynamic Systems Development Method). Marc Latest AAL Article My blog Join my forum!
Sign In·View Thread·PermaLink

Another spear in my arsenal

Gary R. Wheeler

15:46 20 Aug '03

Thanks guys. The guy two levels up from me in the food chain is a mechanical-engineer-turned-MBA Suspicious

who has been positively frothing over with buzzwords: "lean practices", "process", "takh[sp?] time" etc. Sigh

. In self-defense, I need to start researching software management methodologies, so I can dissuade him from the notion that software development can be transformed into a 'turn-the-crank' process.

Software Zen: delete this;

Re: Another spear in my arsenal

jdunlap

15:49 20 Aug '03

Glad to be of service. Good luck! "Blessed are the peacemakers, for they shall be called sons of God." - Jesus "You must be the change you wish to see in the world." - Mahatma Gandhi
Sign In·View Thread·PermaLink

Re: Another spear in my arsenal

jdunlap

15:54 20 Aug '03

Be sure to emphasize that software is not, and at present, cannot, be a mass-production thing. It's still a craft, and will be for some time. Where the big money comes in is selling lots of copies of the product, and you're generally not going to get good money from a product that's poor-quality because it was rushed and under-funded.

"Blessed are the peacemakers, for they shall be called sons of God." - Jesus

"You must be the change you wish to see in the world." - Mahatma Gandhi

Re: Another spear in my arsenal

Marc Clifton

16:00 20 Aug '03

1. Leave a copy of "Death March" on his desk.

2. Send him links to some of the comments in the "What is Extreme Programming" article, especially the not so nice ones.

3. Give him the link to Jeff Sutherland's website.[^]. Even a monkey should be able to see through the drech and hype of:

Innovate faster. Eat your competitor's lunch!
Communicate benefits clearly. Get more resources!
Design systems better. Build better software!
Use agile processes. Deliver faster, better, cheaper!
Deploy quality systems. Capture customer loyalty!

Big Grin

Marc

STL, a liability factory - Anonymously
A doable project is one that is small enough to be done quickly and big enough to be interesting - Ken Orr

Latest AAL Article
My blog

Is SCRUM an acronym?

Dauger

5:00 20 Aug '03

What does it stand for?
Sign In·View Thread·PermaLink

Re: Is SCRUM an acronym?

srisan

8:04 20 Aug '03

SCRUM is a term from Rugby. Just like in Football we have the line of Scrimmage, in Rugby we have Scrummage == the forwards of each side come together in a tight formation and struggle to gain possession of the ball when it is tossed in among them. The same concept would apply in this Software approach, where everyone gathers as a team to reach the goal.
Sign In·View Thread·PermaLink	1.00/5 (1 vote)

Polling x Event-based strategies.

Daniel Turini

2:51 20 Aug '03

Hi, Marc: first of all, let me praise you for your excelent work on your articles on design and methods.

Now,
"Questions
The Scrum Master asks the developers 3 important questions at every SCRUM meeting:
What have you accomplished since the last meeting?
Are there any obstacles in the way of meeting your goal?
What will you accomplish before the next meeting?
"
I think that this is a common flaw in all methods I saw: they suppose the project leader is not a developer, and he needs to be polling often the staff to get a "status refresh". This leads to wasted resources. I think that a better approach would be (actually, it's what I use, and it works great):

"The Scrum Master (or whatever the name you prefer) is the best developer you find on the staff assigned to the project. No other developer should let the work stop, at any excuse, for more than one hour, and should interrupt the Scrum Master whenever an obstacle is found and ask for help. The Scrum Master then takes the appropriate steps to remove the obstacle. The Scrum Master is also notified by e-mail, bugzilla alert (or even a shout 'hey, I'm done!' if they are on the same room) wherever a task is finished."


// Quantum sort algorithm implementation
while (!sorted) 
     ;

Re: Polling x Event-based strategies.

jdunlap

11:17 20 Aug '03

Actually, my mistake. I was supposed to note here that the SCRUM Master must be a part of the development team. That's in my notes, but I didn't put it in like I should have. I'll get that corrected. "Blessed are the peacemakers, for they shall be called sons of God." - Jesus "You must be the change you wish to see in the world." - Mahatma Gandhi
Sign In·View Thread·PermaLink

Re: Polling x Event-based strategies.

Marc Clifton

16:06 20 Aug '03

Daniel Turini wrote:
Hi, Marc: first of all, let me praise you for your excelent work on your articles on design and methods.

Dang, I'm really going to have to put a Preface on these articles, that Justin is doing the research and writing 95% of the article. This article, like "What is Extreme Programming" is the pure research result, which Justin is doing for me to help with the "Methods in C#" book I'm writing. The kudo's go to him. Big Grin

Daniel Turini wrote:
The Scrum Master (or whatever the name you prefer) is the best developer

You are correct (as I believe Justin also said)--the SM (whatever acronym you prefer Big Grin

) is most likely the best developer.

Big Grin

Marc

STL, a liability factory - Anonymously
A doable project is one that is small enough to be done quickly and big enough to be interesting - Ken Orr

Latest AAL Article
My blog

Re: Polling x Event-based strategies.

Andreas Schliep

2:43 11 Jul '05

Hi folks,

as a Scrum practitioner and Certified Scrum Master myself, I have to object to the idea that the ScrumMaster role should be performed by the best developer in a team.

First of all, a ScrumMaster needs to deal with any impediments arising in the project. They can be management issues, team communication problems or lack of technical resources, for an instance. This takes a considerable amount of time - which obviously should not be subtracted from the amount of time the 'best' developer has to work on the code.

Second, a ScrumMaster has to be close to both developers and customers (A.K.A. product owners). This requires communication and facilitation skills in addition to domain and technical understanding. Real good developers have those skills - in my opinion - not in such an extensive manner as real good coaches or facilitators.

Third, the Daily Scrum's 3 questions are not meant as a report to the ScrumMaster. They are supposed to keep the other team members informed about one's own progress and impediments. The ScrumMaster might take some notes for his own report - but his main responsibility is to ensure the team has everything it needs to continue with it's work.

So if it comes to look for a good potential ScrumMaster in your team, pick your best team player and make him team captain.

----
Andreas Schliep
WEB.DE AG

Last Visit: Friday, September 5, 2008 8:31 PM Last Update:Friday, September 5, 2008 8:31 PM

General News Question Answer Joke Rant Admin

What is SCRUM?

Contents

License

About the Authors

Other popular Design and Architecture articles: