- lightweight because it has few prescribed elements
- Three roles: Team, Scrum Master (often a Project Manager), Product Owner (often a Product Manager)
- Three meetings: Sprint Planning, Daily Scrum, Retrospective
- Three artifacts: Product Backlog, Sprint Backlog, Burndown chart
- agile because it maximizes responsiveness to changing customer needs
- a process framework because it is not a process, but a collection of practices and concepts around which a process can be built
The Benefits of ScrumDifferent stakeholders want different things from a software development process.
- Developers want to write code, not documents.
- Quality Assurance engineers want to create test plans that ensure product quality, and have high-quality code to test.
- Project Managers want a process that is easy to plan, execute, and track.
- Product Managers want features implemented quickly, with no bugs.
- Services and Support personnel want to know exactly what is in all product releases, and have a reliable means to satisfy customer requests for bug fixes and enhancements.
- Sales personnel want to know what is “in the pipeline” for future releases.
- Customers want all of their feature requests and bug-fixes done quickly.
- Executives, Program Managers, and PMO personnel want to know exactly what is happening, and what is planned to happen.
- Everyone wants happy customers.
- Team satisfaction and productivity are maximized when effort spent on non-deliverable items (e.g., internal documentation) is kept to a minimum.
- Maximizing quality at each stage minimizes re-work at following stages, and maximizes product quality seen by customers.
- Responsiveness is best achieved by fulfilling customer requests quickly.
- Project status and plans should be visible to everyone who has an interest in them.
How Scrum Provides its BenefitsThe following sections describe how Scrum practices produce the desired benefits.
Team Satisfaction and ProductivityThe “team” consists of the development and Quality Assurance engineers who do the hands-on work of creating a high-quality product. Team members generally find their greatest satisfaction when they can do work that is rewarding.
- For developers, this means designing and writing computer software.
- For QA engineers, this means defining the exact criteria for success through the test cases they develop.
- For all team members, this means producing something they are proud of.
- All are in the same building
- All are in the same city
- All are in time zones that overlap at least four hours per day
- All are willing to spend hours per day outside normal working times (e.g., transoceanic teams).
Maximizing QualityTeams implement Stories to the requirements, in a very literal sense: An implementation is not complete (a story is not “done”) unless it satisfies the requirements, as defined in the test cases. While test-driven development is not required for Scrum, test cases do define whether the requirements have been met, and no story is complete unless it passes all of its test cases. If bugs arise, developers fix them until the tests succeed. This practice ensures that each Story implementation is bug-free, with respect to the requirements, at the time of its completion. It does not prevent regression bugs, so additional testing is necessary after all development is frozen. However, the quality of the product going into regression testing is higher than is the case for products going into the final test period for waterfall projects, and high quality ripples through all stages of the process.
Maximizing Responsiveness to CustomersResponsiveness means providing turnaround to customer requests in a manner that is consistent with customer priorities. Since instant turnaround is not possible, the next best thing is to respond quickly to high priorities, and less quickly to low priorities. The only way to deliver any new feature or bug-fix quickly is to work in short development cycles, which is why the basic unit of Scrum development, the “Sprint,” is typically 2-4 weeks in length. Longer cycles, composed of two or more Sprints, are also common and often referred to as “Releases” (which is not a Scrum term). Productivity and job satisfaction both require that people are productively employed, not sitting idle, which means that parallel work for team members is the norm. The two strategies for parallelizing work on a set of Stories are
- Parallel work on serial Stories. The whole team collaborates on one Story, until completion, then begins work on the next.
- Parallel work on parallel Stories. Each team member works on a different Story, until completion, then starts on another one.