What is Scrum?

Scrum is a simple framework for getting work done. Much of the framework assumes you are getting work done with a small stable dedicated team (from 5-9 people). Usually the work is new product development or specifically software development.

The framework of Scrum defines 3 roles: Product Owner, ScrumMaster and the Team role (or Implementer role).

• The Product Owner owns the Product Backlog and manages the flow of business information into the Team.
• The ScrumMaster is the impediment-remover-in-chief.
• The Team (implementor) role represents the implementers, the people who do the “real work.”

All 3 roles together form the full Scrum Team, aka, the committed ‘pigs.’  Scrum assumes there are also ‘chickens’ (those supporting the project but not committed in the same way).

The framework defines several key meetings.  They are as follows:

• The Sprint Planning Meeting is where the Scrum Team plans the sprint.  A Sprint is a 1 to 4 week timebox, at the end of which the Scrum Team should have produced working product.
• Each work day the Team has a short Daily Scrum, where they sync up about the work remaining to be done in the Sprint.
• At the end of the Sprint, there is a Sprint Review (Demo), where the customers or business stakeholders look at the working product and give feedback (both positive and negative is expected).
• And finally, the Scrum Team meets for a Retrospective, to see how they can work more productively and to remove one good-sized impediment.

All of these meetings are timeboxed.

The simple framework of Scrum does not define what happens before Sprinting (doing Sprints), except to imply that a Vision and a Product Backlog have somehow ‘appeared.’  Virtually all Scrum Teams do Release Planning before doing any Sprints, and Release Plan Refactoring with each Sprint.  In Release Planning the Team and others create a Release Plan (it is a way of looking at the Product Backlog).

The Scrum Team uses many artifacts.  The main ones are the following:

• The Product Backlog holds a list of the PBIs (product backlog items) or features to be built.  Often the PBIs are in the form of User Stories (“As a role X, I want to do Y, so that Z.”) .
• In Sprint Planning, the Team creates a Sprint Backlog (the plan for the Sprint.).  This includes the PBIs that the Team has committed to, as well as the Tasks that the Team currently expects to use to get all the PBIs done.
• Most Scrum Teams track work remaining in a Sprint Burndown Chart — at the Sprint level.  And in a Release Burndown Chart — at the Release level (very typically a Release takes 2-20 Sprints to complete).
• The team produces Working Product at the end of each Sprint.  Ken Schwaber’s phrase for this is a mouthful: “potentially shippable product increment.”  The Working Product is also said to be ‘done, done’ (rather than ‘done, done, done’).  The Working Product (eg, new items built in the Sprint) is presented in the Demo in the Sprint Review meeting, which enables far better feedback than using documentation. The Definition of Done defines when something is ‘working.’
• Finally, the Scrum Team has a public Impediments List.  The ScrumMaster ‘owns’ and works the Impediment List in much the same way as a Product Owner ‘owns’ and works the Product Backlog.

For further information about Scrum, we next recommend the Scrum Guide and The New New Product Development Game article by Takeuchi and Nonaka.