Scrum is a model for the organization and workings of small teams building complex products that solve end-user problems and, more generally, create value for some constituency. The constituency comprises end users, a development team, and a Product Owner. The model reflects two foundations: one-by-one swarmed production, and kaizen mind.

One-by-one Production: Swarming

The development team is a small, self-contained passionate group that solely builds a series of product increments. The increment is the smallest recognized division of work. Each increment creates value, usually by solving a problem for the team's constituency. The team develops each increment to a point of no more known remaining work. The whole team works together on one increment at a time. Once initiated, work on an increment progresses without pause towards its real-world application; no increment is ever set aside in deference to any other work. There is no single central coordinating, leading, or directing role on the team, but the team as a whole manages itself.

To increase the chances of success, a Product Owner works with end users to identify and explore contextualized problems. The Product Owner, end users and developers together design, refine and evaluate business solutions. They together conceive a product increment that will enable the business solution. The Product Owner orders these increments for deployment. The Product Owner and developers should break down large increments to reduce risk. The number of increments in play should be manageably small and the Product Owner, developers and end users together should continually refine the delivery ordering of those increments, as well as their understanding of those increments, to the degree deemed necessary by developers.

Kaizen Mind

The greatest value flowing from a Scrum team is learning. The team regularly sets goals to measurably improve end-user responsiveness, product quality, and quality of work life for the team and for the well-being of end users. An important focal point is the ability of the team to deliver solutions to end-user problems, with key considerations being effectiveness of solutions and efficiency of the process.

The team should usually have one, and only one, kaizen effort in progress at any time. While product kaizens are commendable, the focus should be on tailoring of and improvements to the process. Developers and the Product Owner should regularly and frequently pause from development to review improvement efforts, with working improvements retained and unremarkable efforts reverted. In all cases the evaluation criteria are empirical; most are objective, though important subjective empiricisms, such as overall end-user satisfaction, should also be given weight.

A process improvement may be a one-time advancement in technique, practices or tooling, or may be an adjustment to feedback loops as development progresses from a highly unstructured beginning through to a more structured and detail-oriented finish.

Afternote

It is not meaningful to apply any metric, evaluation, or measure of compliance derived from this guide. The guide is intentionally incomplete while still defining an idealistic endpoint that might inspire positive change. There is no scale of any kind demarcating progress from a team's beginnings through its march toward excellence: such a march is ever ongoing.