SCRUM History

Originally, SCRUM was developed for the management of software development projects. However, it can be very effective for software maintenance teams, or even when leveraged as a program/project management tool.

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

SCRUM Defined

SCRUM is a process framework that includes a set of practices and prescribed roles. The main roles in SCRUM are the "SCRUMMaster" who maintains the processes and has the same responsibilities as a project manager, the "Product Owner" who represents the 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", a prioritized set of high level requirements decomposed into user stories. The backlog items to be included into the upcoming sprint are determined during the first half of the Sprint Planning meeting.

During the planning meeting, the Product Owner and the team discuss all the items in the product backlog to be delivered. The challenge for the team is to determine how much of this backlog can be committed to for completion during the next sprint. Once the sprint has begun, it is not acceptable, or permissible to change the sprint backlog. This implies that the requirements (user stories) identified are committed to and locked-down for that sprint. After a sprint time-box is completed, the team demonstrates the functionality or benefit of the incremental deliverable of the solution being 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 for the duration of the project.

SCRUM confronts and mitigates tactically, 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 with the traditional protocols and/or, prescribed linear 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, not clearly predefined, nor static. Secondly, by placing the focus instead on development cability of the team to complete deliverables expeditiously (reduce cycle-time), and respond with flexibility to ever-changing requirements, between iterations.

While there exists several creative accessories for managing the SCRUM process including scratch pads, post-it stickers, number cards, whiteboards, and innovative software packages; the greatest advantage of SCRUM is that it requires a very flat learning curve, and very little implementation effort for the performing 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 develops user stories from high-level requirements, prioritizes them, then places them in the product backlog (in a PMIS or spreadsheet).

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

SCRUM Master
The SCRUM Master 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 SCRUM Master 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 reresented 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)
Customers, vendors, Senior Management, 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 successfuly delivery of the product.

SCRUM Meetings

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 prioritized list of Project Backlog items including the estimated time it will take to do the required work. This should be discussed with the entire project team who will identify, select, and explain how much of the work can be committed to be accomplished during the upcoming Sprint iteration.

Daily SCRUM Meeting
Normally, on a daily basis during each spring 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 helfd 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 SCRUM Master should take a note of any impediments mentioned by the team members.

Sprint Review Meeting
At the end of a sprint cycle, two meetings should be scheduled: The "Sprint Review Meeting" and the "Sprint Retrospective". Prior to the review meeting, the Scrum team, the Product Owner and the SCRUM Master will review the work completed and pending. During the review meeting, the Scrum team will present the deliverable completed to the stakeholders to be reviewed as a demonstration. Incomplete deliverables should not be demonstrated. There should be a 2-4 hour time limit set aside for this meeting.

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 constructive answers to these questions, the Scrum team along with the Product Owner and the SCRUM Master, should put forward continuous process improvement action items. There should be a 1-2 hour time limit for this phase.

SCRUM Artifacts (tools and techniques)

Product backlog
The product backlog is a master document with all functionality (requirements) required for the entire project. It contains backlog items: clear descriptions of all required features, wish-list items, etc. prioritized by business value. It represents the essence of the solution which will be finally delivered. The requirements in the product backlog are open and editable by all and there are rough estimates of both business value and development effort (sizes) for each requirement. Those high-level estimates facilitate the Product Owner with forecasting the overall project 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 will probably be higher.

The product backlog remains property of the Product Owner who establishes the user stories, articluates the business value and sanctions the business rules. The development effort is the responsibility of the Scrum 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/customer, plus the estimates (sizes) determined by team members, regarding the perceived effort to complete the various features of the user stories.

The sprint backlog may be described in a document containing granular information about 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 Scrum team members log hours spent on each task. The SCRUM Master monitors the sprint backlog to ensure it is properly updated to reflect the tasks that have been completed, and how much time remains to complete the tasks that might be pending. 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 become an integral part of the development effort. The customer must be genuinely interested 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 non-conformance, 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 (Scrum) 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.

SCRUM Master
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, SCRUM Master 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 successfuly 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 practice of involving users groups, business representatives, and stakeholders in providing 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.