| 
Roles 
Practices 
Core Practices Practice | Description |
|---|
Pre-game planning and staging | During Pre-game Planning, all stakeholders can contribute to creating a list of features, use cases, enhancements, defects, and so forth, recorded in the Product Backlog. One Product Owner is designated its owner, and requests are mediated through her. During this session, at least enough work for the first iteration is generated, and likely much more. Starting at these meeting and evolving over time, is identification of the Release Backlog, the subset of the Product Backlog that will make the next operational or product release. | Sprint planning | Before the start of each iteration or Sprint two consecutive meetings are held. In the first, stakeholders meet to refine and re-prioritize the Product Backlog and Release Backlog, and to choose goals for the next iteration, usually driven by highest business value and risk. In the second meeting, the Scrum Team and Product Owner meet to consider how to achieve the requests, and to create a Sprint Backlog of tasks (in the 4 16 hour range) to meet the goals. If estimated effort exceeds resources, another planning cycle occurs. As the iteration proceeds, the Sprint Backlog is updated, often daily during the early part of the iteration, as new tasks are discovered. As a history of many Sprint Backlogs grows, the team improves their creation of new ones. | Sprint | Work is usually organized in 30-calendar-day iterations; each is called a Sprint. | Self-directed and self-organizing teams | During an iteration, management and the Scrum Master do not guide the team in how to fulfill the iteration goals, solve its problems (other than to make decisions when requested, and remove reported blocks), nor plan the order of work. The team is empowered with the authority and resources to find their own way, and solve their own problems. This hands-off approach for 30 days, except to provide resources and remove blocks, is perhaps the most personally challenging aspect for management adopting Scrum. | Scrum meeting | Each workday at the same time and place, hold a meeting with the team members in a circle, at which the same special Scrum questions are answered by each team member. Details are described in the next section. | Don't add to iteration | During an iteration, management does not add work to the team or individuals. Uninterrupted focus is maintained. In the rare case something has to be added, something else should ideally be removed. But, before each new iteration, the Product Owner and Management have the right and responsibility to re-prioritize the Product Backlog, and indicate what to do in the next iteration, as long as the work request estimates don't exceed the resources. | Scrum master firewall | The Scrum Master looks out to ensure the team is not interrupted by work requests from other external parties, and if they occur, removes them and deals with all political and external management issues. The Scrum Master also works to ensure Scrum is applied, removes reported blocks, provides resources, and makes decisions when requested. She also has to take initiative when she sees during the meeting that someone isn't completing work, if the team doesn't speak up. | Decision in one hour | Blocks reported at the Scrum Meeting that require decisions by the Scrum Master are ideally decided immediately, or within one hour. The value of "bad decisions are better than no decisions, and they can be reversed" is promoted. | Blocks gone in one day | Blocks reported at the Scrum Meeting are ideally removed before the next meeting. | Chickens and pigs | During the Scrum Meeting, only the Scrum Team can talk (the pigs). Anyone else can attend, but should remain silent (the chickens), even the CEO. An exception is management (e.g., CEO) feedback on survival points or explanation of the business relevance of the team's work. The Scrum needs to be a vehicle for communicating the product vision and organization goals. From this story: A pig and chicken discussed the name of their new restaurant. The chicken suggested Ham n' Eggs. "No thanks," said the pig, "I'd be committed, but you'd only be involved!" | Teams of seven | Scrum can scale to large projects, but recommends one team have a maximum of seven members. Larger projects are multi-team. | Common room (preferred) | Ideally, the team work together in a common project room, rather than separate offices or cubes. Separate, private space is still available for other activities. However, teams composed of geographically spread members, participating by speakerphone in the Daily Scrum, have reported success. | Daily build | At least one daily integration and regression test across all checked-in code for the project. The XP practice of Continuous Integration is even better. | Sprint review | At the end of each iteration, there is a review meeting (maximum of four hours) hosted by the Scrum Master. The team, Product Owner, and other stakeholders attend. There is a demo of the product. Goals include informing stakeholders of the system functions, design, strengths, weaknesses, effort of the team, and future trouble spots. Feedback and brainstorming on future directions is encouraged, but no commitments are made during the meeting. Later at the next Sprint Planning meeting, stakeholders and the team make commitments. "Power Point" presentations are forbidden. Preparation emphasis is on showing the product. |
The Scrum Meeting: Details The Scrum Meeting or scrum is the heartbeat of Scrum and the project. Each workday at the same time and place, hold a meeting with the team members standing in a circle, at which time the same special questions are answered by each member: What have you done since the last Scrum? What will you do between now and the next Scrum? What is getting in the way (blocks) of meeting the iteration goals?
I've added two more questions since shortly after starting to apply Scrum in 1998 that have been useful:[3] [3] These additional questions have been reviewed and approved by Schwaber and Sutherland, the Scrum founders.
Any tasks to add to the Sprint Backlog? (missed tasks, not new requirements) Have you learned or decided anything new, of relevance to some of the team members? (technical, requirements, …)
The last question provides an efficient forum for a continuously improving and learning group vital to agile development and is often an interesting way to end the reports, increasing their perceived value. Other points: The meeting is ideally held in a stand-up circle to encourage brevity. On average, 15 or 20 minutes for 7 10 people. Longer meetings are common near the start of an iteration. Non-team members (chickens) are outside the circle. It is held next to a whiteboard at which all the tasks and blocks are written when reported. The Scrum Master erases blocks only once they've been removed. There is a speaker-phone for offsite member participation which is required. The Scrum Master ensures the rules are followed and prepares the location for an efficient meeting. Must start on time. Late fines collected by the Scrum Master and donated to charity are a popular rule. Chickens and Pigs rule enforced: Non-team members don't talk or ask questions. An exception is management feedback on survival points or explanation of the business relevance of the team's work. The Scrum needs to be a vehicle for communicating the product vision and organization goals. No other discussion is allowed beyond the three (or five) questions. The Scrum Master has authority to refocus the discussion. If other issues need discussion, secondary meetings immediately after the Scrum Meeting occur, usually with subsets of the team. For example, during the Scrum meeting, I may say to Jill, during her answer report, "We need to talk about that. Let's meet after the Scrum."
The Value of the Scrum Meeting Value: Since there is a self-directing and organizing team, with no manager directing workers or solving problems (unless asked) during an iteration, the Scrum Meeting creates the daily mechanism to quickly inform the team about the state of the project and people. Then, people can take action. External people can observe the daily Scrums to get an accurate, timely, and information-rich measure of progress and issues. It supports openness and allows resolution of dependencies and conflicts in real time to maximize throughput. Value: When a person reports on what they are doing for the next day, they are expressing a kind of social promise to the team. This increases responsibility and follow-through. Value: Scrum is based on the insight that software development is creative and unpredictable new product development, and therefore empirical rather than defined methods are needed. The Scrum Meeting provides the frequent measuring and adaptive response mechanism that empirical methods require. Value: Project risks include not accounting for all tasks, poor estimates, and not quickly resolving blocks. The Scrum Meeting provides a daily forum to update tasks, and surface and remove impediments. Value: It is important to have people (and teams) that are continuously improving and learning. The Scrum Meeting supports this, especially with the addition of Question 5. Unspoken (or tacit) information and knowledge becomes spoken and shared. Value: Shared language, values, and practices help a development team. This is created and reinforced in the daily Scrum. Workproducts In addition to the workproducts illustrated on p. 114, Scrum allows any other workproducts of value to the project. For example, it can be combined with some UP practices, and one can create a Vision or Risk List, using UP terminology. Product Backlog A sample, partial Product Backlog is shown in Figure 7.3. Note that all conceivable items go in the backlog and are prioritized by the Product Owner. The estimates (in person-hours of effort) start as rough guidelines, refined once the team commits to an item. Figure 7.3. sample Product Backlog 
Sprint Backlog A sample Sprint Backlog is shown in Figure 7.4. Note the daily estimate of work remaining for each task; these columns also show the date (e.g., 6 of Jan) and total hours remaining on each day (e.g., Jan 6, 362 hours). It is updated daily by the responsible members or by a daily tracker who visits each member. New estimates are allowed to increase above the original estimate. The simplest (and thus preferred) tool is a spreadsheet; Sutherland uses a customized version of the open-source GNU GNATS tracking tool, with a Web interface. Figure 7.4. sample Sprint Backlog 
Sprint Backlog Graph A Sprint Backlog Graph is shown in Figure 7.5. It is a visual summary of estimated task hours remaining in the Sprint Backlog. In Scrum, this is considered the most critical project data to track. Recommended: Post an updated version of this each day on the wall by the Scrum meeting. Figure 7.5. sample Backlog Graph 
Other Practices and Values Workers daily update the Sprint Backlog Once tasks are underway, individuals are responsible for daily updates estimating the time remaining for their tasks. No PERT charts allowed A PERT chart is built on the assumption that the tasks of a project can be identified, ordered, and reliably estimated, that there is minimal change and noise in the system, and in general that a defined process can be applied. This is inconsistent with the recognition in iterative and agile methods that software is semi-chaotic new product development with high degrees of change and noise, and defined processes can't apply. Scrum Master reinforces vision She needs to daily share and clarify the overall project vision, and goals of the Sprint, perhaps at the start of the Scrum meeting. Replace ineffective Scrum Master The manager/Scrum Master is the servant of the developers, not vice versa. If Scrum Master is not removing blocks promptly, acting as a firewall, and providing resources, the Scrum founders encourage replacing the Scrum Master.
|
