Scrum involves a paradigm shift from control to empowerment, from contracts to collaboration, and from documentation to code.
"The change engendered by Scrum can best be described by thinking of how a house is built. The buyer of the house cannot move into the house until the entire house is completed. Suppose that there were an incremental, iterative approach for home construction. Suppose that using this approach, houses were built room by room. The Scrum lets buyers have software built in this fashion."
The Scrum development framework consists of the following interrelated aspects:
Scrum is structured to regularly make the state of the project visible to the Scrum Team so that it can rapidly adjust the project to best meet its goals.
A Scrum Team consists of
Note: The Product Owner acts as an interface with the stakeholders (managers, executives, publishers, etc.).
Note: While the traditional project manager is responsible for defining and managing the work, the ScrumMaster is responsible for managing the Scrum process, taking care of the practices, meetings and artifacts.
The ScrumMaster is a facilitator (or coach), not a manager.
The Scrum framework is built around an iterative workflow composed of timeboxed (2-4 weeks) iterations called Sprints.
| Release 1 | ... | Release N | ||||||||||||||||||||||||||||
|
|
... |
|
|||||||||||||||||||||||||||
A Sprint
Note: It is generally recommended not to have managers or others in positions of perceived authority attend the Daily Scrum.
Note While continuous builds, automated unit tests, and frequent demonstrations of working code are all ways to focus attention on the product, retrospectives focus attention on how the team does their work and interacts.
Releases are a set of sprints meant to bring a game with major new features to a near-shippable state. A typical release lasts between two to four months. Releases establish longer-term goals for the Scrum Team.
The Product Backlog captures the requirements for the product being developed; it is never complete and evolves as the product and the environment evolve. The Product Owner is responsible for its contents, prioritization and availability.
| Item description |
Initial estimate |
Adjustement factor |
Adjusted estimate |
Remaining time | |
|---|---|---|---|---|---|
| 1 | 2 | ||||
| Item A | 1 | 0.2 | 1.2 | 1.2 | 0 |
| Item B | 2 | 0.2 | 2.4 | 2.4 | 0 |
| Sprint 1 | 3 | 0.2 | 3.6 | 3.6 | 0 |
| Item C | 4 | 0.2 | 4.8 | 4.8 | 4.8 |
| Item D | 1 | 0.2 | 1.2 | 1.2 | 1.2 |
| Sprint 2 | 5 | 0.2 | 6.0 | 6.0 | 6.0 |
| Item E | 1 | 0.2 | 1.2 | 1.2 | 1.2 |
| Item F | 3 | 0.2 | 3.6 | 3.6 | 3.6 |
| Release 1 | 4.8 | 4.8 | |||
| ... | ... | ... | ... | ... | ... |
| Release 2 | ... | ... | |||
The Sprint Backlog lists the tasks defined by the Team to turn the selected Product Backlog into an increment of potentially shippable product functionality. Each task should take roughly 4 to 16 hours to finish. Only the Team can change the Sprint Backlog.
| Task description |
Originator | Responsible | Status (*) | Hours of work remaining | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | ... | 30 | ||||
| Task 1 | Dave | Not started | 2 | 2 | 2 | 2 | 2 | 2 | ... | 2 | |
| Task 2 | John | Not started | 3 | 3 | 3 | 3 | 3 | 3 | ... | 3 | |
| Task 3 | Bob | Not started | 1 | 1 | 1 | 1 | 1 | 1 | ... | 1 | |
| Task 4 | Bob/Dan | Not started | 5 | 5 | 5 | 5 | 5 | 5 | ... | 5 | |
| Task 5 | Dan | Not started | 2 | 2 | 2 | 2 | 2 | 2 | ... | 2 | |
The Spring Burndown Chart shows, each day, a new estimate of how much work (measured in person hours) remains until the Team’s tasks are finished. Ideally, this is a downward sloping graph that is on a trajectory to reach "zero effort remaining" by the last day of the Sprint.
The Product Increment is a "complete" and potentially shippable system. It is owned by everyone and is the ultimate measure of progress.
