A high-level picture of how Scrum works (for a more detailed explanation, download The Scrum Guide, the primary reference for the definition of Scrum):
The starting point of a Scrum effort is the Product Backlog. This is simply a list of features and functions that we expect to be developed during the project. Comparing this to a more traditional method, we might say these are the Business Requirements, but unlike requirements which can be more of a specification, Product Backlog items are intentions, problems to be solved, and requests for help that must be discussed with the Scrum Team.
The Product Backlog is represented by the Product Owner, who has authority regarding the list and priorities. The Product Owner and the Scrum Team join together during a Sprint Planning Meeting at the beginning of an iteration that will last for one month or less to review the Product Backlog. We call this iteration the Sprint. The Team decides which features and functions have the highest priority, and which of those highest-priority items can be worked on during the next Sprint. The Sprint length should be set at one month or less, with two-week Sprints being quite common.
The selected items are moved to the Sprint Backlog, where they are broken down into smaller, manageable pieces of work. The Sprint Backlog will be used to guide the team during the upcoming Sprint. The Scrum Team meets daily during the Sprint at the Daily Scrum Team Meeting, tracking the work of the Sprint verbally as well as with some form of a visual progress chart, such as the Burndown Chart shown above, and identifying obstacles that are keeping them from making progress.
At the end of the Sprint, the Scrum Team meets with interested stakeholders at the Sprint Review to share the work that was completed. Decisions are made during this meeting regarding the potential deployment of what has been developed so far. The Scrum Team also holds a Sprint Retrospective to review their productivity, how they work together, and how they can improve.
We then loop back to the next Sprint Planning meeting where we identify and select items to work on during the next Sprint.
In addition to the framework overview above, Scrum creates an environment that expects and promotes self-managed teams, iterative processing, empirical thinking, and a high degree of visibility into the project and the organization. Implementing Scrum is much more than changing a process, it is changing the way we think.
Scrum for software was developed by Ken Schwaber and Jeff Sutherland. Ken’s book, “Agile Project Management With Scrum,” or Mike Cohn’s “Succeeding With Agile,” are great sources of information regarding this approach to getting work done. Since the agile software revolution that began in the 1990s, Scrum has moved beyond software into organizations that do not focus on software, such as marketing, legal, manufacturing, ministries, defense, etc.
If you would like to learn more, call us at 954-784-3674, or email us.