Scrum Overview

Beyond Traditional Development

Traditional development with single-function groups, delayed or weak feedback loops, front-loaded predictive planning, and a sequential flow from analysis to test is not very successful in today’s volatile world. This approach delays feedback, learning, and potential return on investment due to an absence of real working software until late in the game, causing a lack of transparency, lack of ability to improve, reduction in flexibility, and an increase in business and technical risks. 

An alternative – cross-functional teams with iterative development – has also existed for decades, but was not as widely used as the traditional model.

Scrum packages proven product-development concepts in a simple framework, including: real teams, cross-functional teams, self-managing teams, short iterative full-cycle feedback loops, and lowering the cost of change. These concepts increase agility and feedback, enable earlier ROI, and reduce risk.

Overview

Scrum is a development framework in which cross-functional teams develop products or projects in an iterative, incremental manner. It structures development in cycles of work called Sprints. These iterations are no more than four weeks each (the most common is two weeks), and take place one after the other without pause. The Sprints are timeboxed – they end on a specific date whether the work has been completed or not, and are never extended. Usually Scrum Teams choose one Sprint length and use it for all their Sprints until they improve and can use a shorter cycle. At the beginning of each Sprint, a cross-functional Team (of about seven people) selects items (customer requirements) from a prioritized list. The Team agrees on a collective target of what they believe they can deliver by the end of the Sprint, something that is tangible and will be truly “done”. During the Sprint, no new items may be added; Scrum embraces change for the next Sprint, but the current short Sprint is meant to focus on a small, clear, relatively stable goal. Every day the Team gathers briefly to inspect its progress, and adjust the next steps needed to complete the work remaining. At the end of the Sprint, the Team reviews the Sprint with stakeholders, and demonstrates what it has built. People obtain feedback that can be incorporated in the next Sprint. Scrum emphasizes working product at the end of the Sprint that is really “done”; in the case of software, this means a system that is integrated, fully tested, end-user documented, and potentially shippable. Key roles, artifacts, and events are summarized in Figure 1.

A major theme in Scrum is “inspect and adapt.” Since development inevitably involves learning, innovation, and surprises, Scrum emphasizes taking a short step of development, inspecting both the resulting product and the efficacy of current practices, and then adapting the product goals and process practices. Repeat forever.