The Scrum Training Series is provided free of charge and used by thousands of Agile practitioners, coaches, and trainers around the world.
Contact Michael James via Twitter.
Script without illustrations.
Scrum is a management framework for incremental product development using one or more cross-functional, self-organizing teams of about seven people each.
It provides a structure of roles, meetings, rules, and artifacts. Teams are responsible for creating and adapting their processes within this framework.
Scrum uses fixed-length iterations, called Sprints, which are typically two weeks or 30 days long. Scrum teams attempt to build a potentially shippable (properly tested) product increment every iteration.
Scrum’s incremental, iterative approach trades the traditional phases of "waterfall" development for the ability to develop a subset of high-value features first, incorporating feedback sooner.
The greatest potential benefit of Scrum is for complex work involving knowledge creation and collaboration, such as new product development. Scrum is usually associated with object-oriented software development. Its use has also spread to the development of products such as semiconductors, mortgages, and wheelchairs.
Scrum’s relentless reality checks expose dysfunctional constraints in individuals, teams, and organizations. Many people claiming to do Scrum modify the parts that require breaking through organizational impediments and end up robbing themselves of most of the benefits.
Scrum is intended for the kinds of work people have found unmanageable using defined processes — uncertain requirements combined with unpredictable technology implementation risks. When deciding whether to apply Scrum, as opposed to plan-driven approaches such as those described by the PMBOK® Guide, consider whether the underlying mechanisms are well-understood or whether the work depends on knowledge creation and collaboration. For example, Scrum was not originally intended for repeatable types of production and services.
Also consider whether there is sufficient commitment to grow a self-organizing team.
The Product Backlog is a force-ranked list of everything we might ever do, prioritized (or "ordered") by the Product Owner. Product Backlog Items (PBIs) are often written in User Story form. One symptom of a less-effective Scrum implementation is a Product Backlog containing conventional tasks rather than well-formed Product Backlog Items representing customer-centric functionality. This is covered in the Backlog Refinement Meeting module.
The Sprint Backlog is the work we're planning to do to achieve the goal of the current Sprint only, typically committed (or "forecasted") PBIs and related Sprint Tasks. While PBIs should focus on the what, Sprint Tasks represent the how. This is covered in the Sprint Planning Meeting module.
While not the most important aspect of Scrum, Scrum teams sometimes use Sprint Burndown Charts, Product Burndown Charts, and Release Burndown Charts, as illustrated in (you guessed it) the Scrum Reference Card.
While beyond the scope of this elearning series, it's worth mentioning that Scrum (and related approaches) have been used with varying degrees of success on large development efforts involving dozens of teams. The most successful examples generally use feature teams, with each team spanning multiple architectural components to deliver end-user value rather than internal handoffs. This will go much better when the organization is committed to overcoming its internal obstacles.