The scrum process is a commonly used development process for agile software projects. The term originated in a 1986 paper by Hirotaka Takeuchi and Ikujiro Nonaka entitled “The new product development game”. They adopted the term scrum from the sport of rugby as they drew the analogy of strength, cohesion and collaboration from this element of the game.
The approach originated in manufacturing, but in 1993 Jeff Sutherland and Ken Shwaber adapted the approach for software development, where it is particularly relevant to iterative and adaptive life cycles.
Sutherland and Shwaber were also members of the group that wrote the Agile Manifesto in 2001 and since then the term scrum has been seen as very closely aligned with the manifesto, despite preceding it by 14 years.
The scrum approach is, in effect, the application of short Shewhart cycles with self-managed, cross functional teams.
Initially, a product owner creates a prioritised wish list called a product backlog. This may be prioritised using techniques such as MoSCoW and individual products may be estimated using techniques such as planning poker.
Although the process is designed to be flexible and quick to deliver products of value, the guiding principles of functions such as requirements management and solutions development are still relevant.
During sprint planning, the development team selects a batch of high priority products that it aims to complete during a sprint (timebox) of, typically, 2 to 4 weeks.
The team meets every day to assess progress and this meeting is facilitated by a ‘Scrum Master’. The scrum master’s role is to keep the team focused, track progress and remove obstacles that may affect the achievement of the sprint’s goals. Views on whether the role of scrum master can, or should, be fulfilled by the project manager are controversial.
The progress of product development across multiple sprints may be visualised in a burn down chart. Progress within a sprint may be monitored using a kanban approach, which gives rise to the term 'scrumban'.
At the end of the sprint, the chosen products should be ready to demonstrate to the product owner or actually be delivered. Any unfinished products are returned to the backlog.
A sprint should end with a review (much like a post project review but on a much smaller scale). The team then selects the next batch of products for the next sprint.
This process can be used in place of the generic development process in the Praxis method.