Scrum is a project management method co-founded (or co-invented) by Ken Schwaber and Jeff Sutherland and was first used in 1994 at Easel Corporation. Ken and Jeff worked together in a number of companies, making Scrum part of those companies’ development practices.

Description

At a more expansive level, however, Scrum is a framework, a value-system, and a process -- and explaining it from each of those perspectives may help different audiences.

Scrum is a framework for managing projects or, more generally, work. It is iterative and incremental, which means that it asks a team to work for a short period of time (a "sprint" or "iteration") and then demonstrate real stuff (a product increment) that matters to the end-product at the end of each sprint. Goals for each subsequent sprint are evaluated, negotiated, and committed to based on the stuff that was created at the end of the previous sprint. There's still an infinite amount of work to be done, but Scrum divides that work into manageable chunks (usually about two-weeks in length).

Scrum is a value system that asks teams to work together to accomplish a common goal, focusing on the output of the team rather than the input of the individuals. It values communication, openness, transparency, self-organization, and the worth of employees as individuals and professionals. Scrum can and does help people feel good about their jobs and their contributions to their teams. It is also in tune with reality, assessing progress and evolving business conditions to dictate a project's direction.

Scrum is a process that invites the application of those values by asking that teams generally organize themselves into three roles, participate in four regular meetings, and produce and maintain three artifacts. This simple process can be scaled (arguably, with additions for larger organizations) to any size software team (or non-software team, for that matter).

Benefits

What are the benefits of Scrum? First, it provides structure without unnecessary bureaucracy or hoops to jump through. This structure regiments communication and makes room for conversations that might otherwise not take place, resulting in less miscommunication. Reduced miscommunication often results in fewer defects and mistakes. Scrum gives both team members and management a voice and increases the day-to-day control individuals have over their work. Unsurprisingly, this results in higher employee retention and satisfaction. Regular interactions help make things visible and transparent earlier than they may with more traditional, heavyweight processes. Output is also considered more valuable than input which means that Scrum helps teams focus on big picture metrics like ROI, not how busy they are or look to managers. Therefore, Scrum helps us make more stuff that works for all the reasons above. If you’re in the business of selling stuff that works, you will probably make more money using Scrum.

Ultimately, that’s what it comes down to: With Scrum, you will probably produce better work for less money, in less time than using any other project management framework, value-system or process.

Details

Let's look at the pieces of Scrum that make it work...

Roles

As defined, Scrum has three primary roles:

• The Product Owner - called the "single-wringable neck" by one large organization, the Product Owner is responsible for understanding the vision of their product (by understanding the business needs and the market needs) and for maximizing the return on investment of the product by prioritizing the work that needs to be done by Scrum teams. Product Owners are usually in continuous contact with their stakeholders, customers, and Scrum teams; they are the final arbiter of prioritization of work and decisions with regard to product requirements.
• The Scrum Master is responsible for enforcing the Scrum process within a Scrum team by ensuring that the required meetings and discussions occur. They keep the team focused on their goals and do whatever they can to support the team's success by removing impediments and reducing interference from outside the team. The Scrum Master is also a team morale booster, constantly working to keep the team motivated and excited about their work.
• The Scrum Team is responsible for building the product. The team is usually between 5 and 9 people in size and is cross-functional, having the skills it needs to do the work it is asked to do. Teams are meant to be collocated in an open, flexible space that supports discussions, posting of information (wall space), and work.

• The Customer or Stakeholder provides the Product Owner with information about their needs and wants with regard to the product and also directly assists the Scrum team to build the product functionality in a way that suits the manner in which customers work.
• The Business Owner provides the funding (resources, hardware, software/tools) for the project.

Artifacts

When using Scrum, the following artifacts are created and used:

• The Product Backlog is a list of features, defects, complaints, etc. about a product that represent the known entirety of the work to be done to a product. As Jeff Sutherland has commented, "If it's not on the Product Backlog, it doesn't exist." The Product Backlog can be contributed to by anyone involved with the product, but is prioritized only by the Product Owner in the way that best maximizes the ROI of the product. Product Backlog items are estimated by the Scrum teams, usually in units called story points, but often in other units such as hours, ideal team days, or ideal person days.
• The Sprint Backlog is created by the Scrum team at the beginning of every Sprint and is the team's representation of all of the work (in terms of tasks) that need to be done to complete the Product Backlog items that the team is committing to do during a Sprint. The Sprint Backlog is made up of tasks that are usually estimated in terms of hours (but may be estimated in basic t-shirt sizes: xs, s, m, l, xl).
• The Sprint Burndown is created by determining the sum of the hours of work remaining during a Sprint and plotting that on a line graph that indicates, on the x-axis, the day of the Sprint and, on the y-axis, the number of hours of work remaining to do. By plotting this information every day, the Scrum Team can track its progress and consult with the Product Owner if there's a possibility that the team's commitment may have to be increased or decreased based on the amount of work yet to do.
• The Release Burndown is created by determining the sum of the points/units of work remaining in the project at the beginning of every Sprint. Like the Sprint Burndown, the Release Burndown is plotted on a line graph with the number of points/units of work to do plotted on the y-axis and the number of the current Sprint plotted on the x-axis. By using this line graph (often by adding a linear trendline), the Product Owner and the Scrum Master can determine if the desired features will be completed within the desired timeframe and usually provides ample warning for the Product Owner and Business Owner to make staffing, schedule, or resource changes to support the necessary outcome of the project.

Constructs/Meetings

When using Scrum, the following constructs or meetings are used:

• The Sprint is a fixed-length iteration that is begun with a Sprint Planning Meeting and ends with a Sprint Review Meeting. Different projects use different Sprint lengths, but are usually defined in terms of 1, 2, 3, or 4 weeks or a full calendar month (e.g., April 1 through April 30). It is within a Sprint that all development work takes place.
• The Sprint Planning Meeting is a one-day meeting of the Scrum team (including the Scrum Master and the Product Owner) and stakeholders on the first day of the Sprint during which the team works to gain a complete understanding of the stories at the top of the Product Backlog so that the work can be turned into tasks, estimated, and added to the Sprint Backlog. By the end of the Sprint Planning Meeting, the team should have a complete Sprint Backlog and will have made a commitment to the Product Owner to do everything in their power to complete that work.
• The Sprint Review Meeting is a one-hour (or less) meeting of the Scrum team (including the Scrum Master and especially the Product Owner) on the last day of the Sprint during which the results of the team's achievements during the Sprint are demonstrated to the Product Owner. Any completed functionality or other deliverable is demonstrated/shown to the Product Owner for their approval. Should the work gain the approval of the Product Owner, the work is considered to be done and is removed from the Product Backlog. Should the work be considered incomplete or incorrect by the Product Owner, the items remain on the Product Backlog for prioritization to be finished by the Scrum team at a later date. Any work not completed by the Scrum team is returned to the Product Backlog to be completed later. The outcome of the Sprint Review meeting is a modified Product Backlog (with completed items removed from the backlog) and a completed segment of the product, ready to be delivered to the customer if desired, or added to the rest of the product to be used as input to the next Sprint.
• The Daily Scrum meeting is a fifteen-minute meeting of the Scrum team wherein each member of the team explains what they have done since the previous daily Scrum meeting, what they plan to do between now and the next daily Scrum meeting, and what, if anything, is impeding their progress. It is an opportunity for the team to examine their current situation and to modify their plans based on the reality of the situation. Because the Daily Scrum meeting occurs every day, it's agenda is tightly controlled by the Scrum Master to ensure that everyone on the teams knows what everyone else is doing. When the daily Scrum meeting is complete, other "sidebar" conversation may continue as a result of the meeting, but those not involved in those discussions are free to return to their work.
• The Sprint Retrospective meeting is a meeting that can take between 30 and 120 minutes. It usually follows the Sprint Review meeting and is attended by the Scrum team (including the Scrum Master and the Product Owner) only. During this meeting, the team discusses the previous Sprint in terms of what worked and what did not. By prioritizing these items in terms of the largest gains in productivity (or whatever other basis the team chooses to use), the team analyzes causes, solutions, and decides what steps to take in the next Sprint to either increase the instances of things that went well and to decrease the instances of things that went poorly. Usually, the team completes the retrospective meeting with between 1 and 3 goals for the next Sprint. As those goals often result in tasks being added to the Sprint Backlog in the next Sprint, it is imperative that the retrospective meeting take place prior to the next Sprint Planning meeting.