According to Ken Schwaber, co-creator of Scrum: “You can’t predict or definitely plan what you will deliver, when you will deliver it, and what the quality and cost will be”.
Scrum is focused on delivering working software regularly, monitor features delivered and adjust plans according to the results. Unlike XP, which puts more emphasis on programming, Scrum has a project management emphasis. It can be applied both to software and non-software projects.
Without presenting Stories and Estimation, the entry below describes the overall Scrum methodology.
Scrum Values
(Scrum Alliance Code of Ethics)
- Commitment and Focus
- Openness
- Respect
- Courage
Bellow is a description of teams involved and the Scrum Process.
Scrum Master
The Scrum Master role is a new management role. Ensures tasks do not change during a Sprint, solves logistic (e.g.: lack of equipment) and organisational (e.g.: slow approvals) problems raised during Daily Scrum Meetings by Scrum Team members. The Scrum Master does not assign roles and has no “power”.
Product Owner
The Product Owner envisions the product and controls the Product Backlog. Product Owners can be a person, a team of customers or in product companies, a product manager. Technical management may be a part of the Product Owner team.
Scrum Teams
Scrum Teams are cross-functional teams, of 7 (+/- 2) members, that perform analysis, documentation, coding and testing; without titles and roles.
.png)
Backlogs
Backlogs identify product features; used for managing the project.
Product Backlog
The Product Owner controls the Product Backlog, by adding business and technology features that define the product. Items in the Product Backlog are prioritised by the Product Owner, and are the starting point for the Release Backlog and Sprint Backlog.
Release Backlog
The Product Owner selects the features that should be in the next Product Release. The Release Backlog is the starting point for the Sprint Backlog.
Sprint Backlog
The Sprint Backlog, developed in the Sprint Planning meeting, defines the work to be accomplished at the end of the Sprint. Unlike the Product Backlog, the Sprint Backlog does not change during a Sprint. This is ensured by the Scrum Master.
Sprint Planning Meeting
“Customers, users, management, the Product Owner and the Scrum Team determine the next Sprint Goal, and functionality at the Sprint Planning meeting. The team then devises the individual tasks that must be performed to build the product increment” – Ken Schwaber.
Depending on the project size, there may be two meetings: one for selecting features, and one for planing the detail tasks.
- Product Owner identifies features required for the next Sprint
- Development Team:
- creates tasks required for delivering those features
- estimates how much can be accomplished
- Development Team and Product Owner cycle through the process, until the planned features fit the available resources for the Sprint
- At the end of the process, a Sprint Goal is established; describing the business purpose of the Sprint
Sprint Goal
The Sprint Goal provides a business purpose for the Sprint; aimed at non-developers but not the end users.
.png)
Sprint
“The team works for a fixed period of time called a Sprint” – Ken Schwaber
The Sprint is the period of time when work gets done. To ensure a steady rhythm, Sprints must have regular intervals, usually of 1 to 2 weeks. During the Sprint, the team self-organizes; with each member choosing tasks from the Sprint Backlog and working to accomplish the Sprint Goal. Each member participates in a Daily Scrum Meeting. No changes are allowed to the Sprint Backlog, to ensure a point of stability.
Daily Scrum Meetings
“Software development is a complex process that requires lots of communication. The Daily Scrum meeting is where the team comes to communicate.” – Ken Schwaber
Daily Scrum Meetings, ensure that each member’s work integrates with the rest of the team’s work. Briefly, each member speaks about their own tasks, raises problems and chooses what to do next. Daily Scrum Meetings are short (up to 15 minutes) informal meetings; and are not Development Meetings. The main focus, is answering the following questions:
- What has been accomplished since the last meeting?
- What the team is going to do before the next meeting?
- What obstacles are on its way?
The Scrum Master is responsible for keeping the meeting short and effective; managers may attend the meetings, to keep track of status but without participating. Each member choosing their own task highlights the self-organising principle of Scrum and Agile. Once committed to a task, work must be finished; with overtime being “permitted” as part of Scrum.
.png)
Sprint Review
“The Sprint Review meeting is a four-hour informational meeting. During this meeting, the team presents to management, customers, users and the Product Owner the product increment that is has built during the Sprint” – Ken Schwaber
At the end of a Sprint, customers and the Product Owner are shown how much functionality has been built; engineers see how the technology was used; and management sees the progress made. This is the starting point for new ideas for what’s next. If a Sprint doesn’t fit all the required work, the next Sprint has it’s workload adjusted. The Product Owner puts items not done back in the Product Backlog (which may or may not be prioritised for the next Sprint Backlog); and items done are released.
Abnormal Sprint Termination
When a Scrum Team discovers it has committed to do too much, technical risks are too high or the business concept doesn’t work, a Sprint may fail. The Scrum Master meets with the Product Owner and the Scrum Team; and adapt the Sprint Backlog.
Monitoring Progress
Scrum monitoring involves one minute per day for developers, and ten minutes per day for project managers. It relies on a Sprint Backlog Graph, displaying days on the horizontal axis, and work remaining in hours on the vertical axis. At the end of a Sprint, the work remaining should be zero.
The Scrum Process Overview
NOTE: This is my first note about Scrum, and relies heavily on course materials from the ‘Agile Methods’ class, at Oxford University, and ‘Agile Software Development Ecosystems’ book, by Jim Highsmith.
Note my skills at drawing arrows.