---

SCRUM History

Originally, SCRUM was developed for the management of software development projects. However, it has been very effective for software maintenance teams, and for projects, when leveraged as a project management approach.

"Back in 1986, Ikujiro Nonaka and Hirotaka Takeuchi described a new holistic approach which increased speed and provided more flexibility in new commercial 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". The case studies come from the automotive, photo machine, computer and printer industries.

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 the early 1990s, Ken Schwaber used an approach that led to SCRUM at his company, Advanced Development Methods. At the same time, Jeff Sutherland, John Scumniotales, and Jeff McKenna developed a similar approach at Easel Corporation and were the first to call it SCRUM. In 1995 Sutherland and Schwaber jointly presented a paper describing SCRUM at OOPSLA 1995 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 titled Agile Software Development with Scrum." From Wikipedia

SCRUM Defined

SCRUM is a process skeleton that includes a set of practices and predefined roles. The main roles in SCRUM are the "SCRUMMaster" who maintains the processes and has the some of the same responsibilities as a project manager, the "Product Owner" who represents the customer and key stakeholders, and the "Team" which includes the developers and product users.

During each "Sprint", usually a 2–4 week period, which is agreed upon by the team, the team creates an increment of functional software component. The set of features that constitutes a sprint is derived from the product "backlog", which is a prioritized set of high level requirements of work scheduled. The backlog items to be included into the upcoming Sprint is determined during the sprint planning meeting.

During the planning meeting, the Product Owner and the team discuss all the items in the product backlog to be completed. The challenge for the team is to determine how much of this backlog can be committed for completion during the next Sprint. Once the Sprint has begun, it is not feasible, or permissible to change the Sprint backlog. This implies that the requirements identified are committed and locked-down for that sprint. After a sprint is completed, the team demonstrates the use of the incremental component of the solution developed.

SCRUM encourages co-location of team members. This enables the creation of self-organizing teams and fosters verbal communication across all team members, while reinforcing team spirit and discipline across the spectrum of the project.

SCRUM confronts and tactically mitigates a very common challenge. There is the understanding that during the life of any given project, product owners (or customers) can change their minds about any given specification and/or need. Such unpredictable behavior presents challenges that cannot be easily mitigated in the usual accepted and/or, traditional planned project management approaches.

Given these challenges, SCRUM takes on a more adaptive approach by first, accepting the fact that product requirements are never fully understood, clearly defined, or static; and secondly, placing the focus instead on the development capability of the team to complete deliverables expeditiously (reduce cycle-time), and respond with flexibility to ever-changing requirements.

While there exists several creative approaches to managing the SCRUM process including scratch pads, post-it stickers, whiteboards, and/or innovative software packages; the greatest advantage of SCRUM is that it requires only a flat learning curve, and very little implementation effort for the organization and project team to get started.

SCRUM Roles and Responsibilities

The Product Owner
The Product Owner (may be considered the Customer, or one who) represents the voice of the customer. The Product Owner ensures that the SCRUM Team is provided with adequate information (requirements and rules) from a business perspective. The Product Owner writes user stories, prioritizes them, and then places them in the product backlog for the team.

The Team
An average SCRUM team comprises about 5-10 individuals having cross-functional skills, but some teams have been known to include up to 500 people. The SCRUM Team (which includes everyone who performs activities to complete the deliverables) does the actual work of developing the solution and has the responsibility to expeditiously deliver the product.

SCRUMMaster
The SCRUMMaster facilitates the SCRUM effort by preventing external (or internal) obstacles from impeding the progress of the project. The prime objective is to ensure the SCRUM team delivers the requirements expeditiously to meet the sprint goals. Because the SCRUM team is self-directed, the SCRUMMaster is not considered the leader of the team. However, he or she acts as a buffer against any distractions for the team and make sure the SCRUM process rules are enforced and the process rolls out as prescribed.

Users
The software being built must be represented by someone who requested it. If a solution does not have a requestor, or a user, it is as if the software was never created and it will ultimately be rejected. Users must be instrumental in testing the component output and provide the necessary feedback to the team.

Stakeholders (customers, vendors, etc.)
Customers, vendors, Senior Management, users, etc., are all considered stakeholders. These are the individuals who enable the project, and ultimately those who will benefit from the agreed-upon deliverables of the project. It is highly recommended that these stakeholders are keenly involved in the process especially during sprint reviews.

Managers
The managers of the performing organization impacted by the SCRUM process must ensure adequate development environment for the successful delivery of the product.

SCRUM Meetings

Daily SCRUM Meeting
Normally, on a daily basis during each Sprint the team holds a project status meeting. This is called a "SCRUM", or "the daily standup" meeting.
There are specific guidelines for this SCRUM meeting; they are:
- The daily meeting should always begin on time.
- Everyone should be welcome to the meeting, but only "pigs" may address the issues
- The meeting should be scheduled for 15-20 minutes depending on the size of the team
- The meeting should be conducted with standing room only
- The meeting should be held in the same location and at the same time, daily


The objective of this meeting is to have each team member answer three specific questions:
1 - What has been accomplished since yesterday?
2 - What has been planned to be accomplished today?
3 - Do you anticipate any obstacle which may prevent you from accomplishing your goal?
The SCRUMMaster should take a note of any impediments mentioned by the team members.

Sprint Planning Meeting
A Sprint Planning Meeting should be scheduled at the beginning of the sprint cycle (every 15–30 days).

Select what work is to be done
The Product Owner should prepare the Sprint Backlog including details of the estimated time it will take to do the requied work. This should be discussed with the entire project team who will identify, decide, and explain how much of the work can be committed to be accomplished during the upcoming sprint 8 hour timebox.

Sprint Review Meeting
At the end of a sprint cycle, two meetings should be scheduled: The "Sprint Review Meeting" and the "Sprint Retrospective". During the review meeting, the entire team, along with the Product Owner and the SCRUMMaster will review the work completed and pending. The project team will present the completed component to the stakeholders to be reviewed as a demonstration. The incomplete deliverables cannot be demonstrated. There should be a 4 hour time limit for this phase.

Sprint Retrospective Meeting
During the retrospective meeting the entire team should reflect on the past sprint and discuss the accomplishments. The objective is to have a clear understanding of two main aspects in retrospect: What went well during the sprint? What did not and should be improved during the next sprint? With answers to these questions the team along with the Product Owner and the SCRUMMaster, should put forward continuous process improvement suggestions. There should be a 3 hour time limit for this phase.

SCRUM Artifacts (tools and techniques)

Product backlog
The product backlog is a master document with all functionality required for the entire project. It contains backlog items: broad descriptions of all required features, wish-list items, etc. prioritised by business value. It represents the essence of that which will be built. The requirements in the product backlog are open and editable by all and there are rough estimates of both business value and development effort for each requirement. Those estimates facilitate the Product Owner with estimating the overall timeline and establishing some priority over the deliverables. For example, if two or more required features have the same business value, the one with the smallest development effort should probably receive the highest priority, because the ROI is presumably, higher.

The product backlog remains property of the Product Owner who establishes the requirements, sets the business value and business rules. The development effort is the responsibility of the project team.

Sprint Backlog
The sprint backlog constitutes a list of tasks that the team has committed to complete in the upcoming sprint. Items on the sprint backlog are selected from the Product Backlog by the team, based on the priorities set by the Product Owner plus the estimation of the team regarding the effort to complete the tasks for the various features.

The sprint backlog is a granular document containing information regarding the approach of the team to implement the features for the upcoming sprint. Features are broken down into tasks. In adherence to best practices, tasks should generally be estimated between 4 -16 hours of work. With this level of detail the entire team understands exactly what needs to be accomplished, and how. Interestingly enough, the tasks selected for the sprint backlog are never assigned; but are voluntarily selected by team members appropriately, according to task priority, effort required, and skills set.
The sprint backlog remains the property of the SCRUM Team and all task estimates are established by the Team.

Burndown
The burndown chart is publicly displayed and highlights the work effort remaining in the sprint backlog. During the sprint, the SCRUMMaster maintains the sprint backlog by updating it to reflect which tasks have been completed, and how much time the team estimates is needed to complete the tasks that remain outstanding. The estimated effort for work remaining in the sprint is calculated daily and graphed, resulting in a sprint burndown chart displayed below:


The sprint burndown chart

SCRUM, an Adaptive Project Management Process

As an agile approach to product development, SCRUM is very flexible, yet disciplined in its own right. Below, a few of the established best practices of SCRUM are briefly discussed.

Customer involvement and communication
It is very important that customers remain an integral part of the development effort. The customer must be genuinely interested in and invested in the outcome of the product.
SCRUM is able to deliver frequent intermediate releases of working functionality to the solution thus, it offers the customer immediate business value by providing iterations of functioning software, earlier. The process also provides the Product Owner the flexibility to change requirements according to changing needs.
As a rule, SCRUM incorporates high transparency in the planning and development of each module. SCRUM requires the inclusion of relevant stakeholders in communications and clarity about who is accountable for what and by when.
SCRUM requires frequent stakeholder meetings to monitor progress. These may be supported by balanced dashboard updates (delivery, customer, user, process, stakeholders)

Quality, issue management, and transparency
Defects management, and issues monitoring should be in place, especially an advance warning mechanism which provides visibility to nonconformance, potential slippage, and/ or deviation from schedule way ahead of time.
All issues should be transparent and discussed. Nothing should be swept under the rug, and no one should be punished for recognizing or identifying any previously unforeseen problem.
Risk identification and mitigation plans are carried out frequently by the development team. Risk mitigation, monitoring and management (risk analysis) occur at every stage in the SCRUM process, and with firm commitment.

SCRUM Common Terms

Product Owner
The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.

SCRUMMaster
The person responsible for the SCRUM process, making sure it is used correctly and maximizes its benefits.

Project Team
A cross-functional group of people responsible for managing itself to develop the product.

SCRUM Team
Product Owner, SCRUMMaster and Project Team

Sprint burndown chart
Daily progress report for a Sprint over the duration of the sprint

Product backlog
A prioritized list of high level requirements from the Product Owner.

Sprint backlog
A list of tasks selected by the team, to be completed during the upcoming sprint.

Sprint
A time period (usually between 2 - 4 weeks) when the development of a set of sprint backlog items to which the Team has committed, takes place.

The PIGs
Pigs are usually those individuals committed to the successful outcome of a project governed by the SCRUM approach. They are the stakeholders with the most to lose or gain depending on the result of the project.

The Chickens
One of the most important aspect of successful project outcome is the best achieved by proactively involving users groups, business representatives, and stakeholders to provide feedback in the process. These participants, called Chickens, are not officially considered part of the SCRUM team, but should be engaged in testing product outputs for review and sprint planning meetings.

---

Credits and recommended readings:
Agile Software Development with Scrum - by Ken Schwaber
Agile Estimating and Planning (Robert C. Martin Series) by Mike Cohn
Agile and Iterative Development: A Manager's Guide by Craig Larman
Credits also to contributors in Wikipedia, the free encyclopedia