What happens at the end of a sprint in Scrum?

At the end of a sprint, the team produces an increment that builds on previous increments. The team can trim functionality but must meet the promised delivery date

Figure: Product increment built on previous increments

After each sprint, all project teams meetwith all stakeholders, including high-level management, customers, and customer representatives. All new information from the sprint just completed is reported. At this meeting, anything can be changed. Workcan be added, eliminated, or reprioritized. Customer input shapes priority-setting activities. Items that are important to the customer have the highest priority.

New plans and estimates are made following the same process discussed under “How do you plan and estimate in Scrum?” Assignments are then made to teams for the next sprint. As sprints finish, estimates become better as planners see what each team has produced in previous sprints. With the small time increments, the planners must be careful in their estimation, because, “Extrapolation of times for the hundred yard dash shows that a man can run a mile in less than three minutes.”

Because each sprint produces a visible, usable, increment, product delivery can take place after any sprint. In fact, delivery of a sort does take place and feedback from the business and marketing side and from customers is a reaction to the current increment’s delivery. Typically, final delivery takes place after a wrap up phase that is run as a final sprint.

The organization can make one very important decision at the end of a sprint: whether to continue product development. Given what was delivered during the last sprint and the current state of the market, the stakeholder meeting should address the question, “Should this project continue?” This is a business decision and must be made after considering all the technical and marketing issues.

As a result of the interaction of small teams in small, focused development cycles:

1. the product becomes a series of manageable chunks,
2. progress is made, even when requirements are not stable,
3. everything is visible to everyone,
4. team communication improves,
5. the team shares successes along the way and at the end,
6. customers see on-time delivery of increments,
7. customers obtain frequent feedback on how the product actually works,
8. a relationship with the customer develops, trust builds, and knowledge grows, and
9. a culture is created where everyone expects the project to succeed.

What happens during a Scrum meeting?

Each team member must answer three questions:

1. What have you completed, relative to the backlog, since the last Scrum meeting?
2. What obstacles got in your way of completing this work?
3. What specific things do you plan to accomplish, relative to the backlog, between now and the next Scrum meeting?

The Scrum meeting should last 15 to 30 minutes, which provides enough time to address obstacles, but does not allow time to brainstorm a solution. All discussion other than responses to the three questions is deferred to a later meeting involving only those actually affected by the discussion. The goals of the Scrum meeting include:

• focusing the effort of developers on the backlog items,
• communicating the priorities of backlog items to team members,
• keeping everyone informed of team progress and obstacles,
• resolving obstacles as quickly as possible,
• tracking progress in delivering the backlog functionality, and
• addressing and minimizing project risk.

Figure: Daily Scrum

Who leads the Scrum team?

The Scrum Master leads the Scrum meetings, identifies the initial backlog to be completed in the sprint, and empirically measures progress toward the goal of delivering this incremental set of product functionality. The Scrum master ensures that everyone makes progress, records the decisions made at the meeting and tracks action items, and keeps the Scrum meetings short and focused.

The Scrum master works constantly to reduce product risk through the incremental delivery of features, rapid response to development obstacles, and continual tracking of the delivery of backlog items.

How do you plan and estimate in Scrum?

Often, the marketing group or the customer will set the release date. With a release date set, the development and marketing groups must work together to provide the features with the highest value for the product’s first release. Marketing should prioritize the features, while the product development group provides estimates for the effort. Marketing and product development must agree on the target set of features. If the product development group cannot deliver the requested features, the groups must negotiate a reduced set of features.

In negotiating features in the release, management must identify available developers for feature development. The number of developers for each team must meet the Scrum recommendation: no more than 10. Of course, you can have several teams. To complete negotiations with the marketing department, the product development group must have the required developers committed to the project for the identified time period.

Once negotiations between the marketing and product development groups are complete, the backlog is allocated to sprints in priority order. The product development group also establishes the target development environment and determines the risks associated with it. While the marketing department understands what the customer needs and the value to the customer, product development members understand the risk of new technologies, tools, or software processes. They identify and address these risks in the decision-making that leads to the feature allocation to sprints. In general, they address risky items in early sprints to allow time to recover if technical difficulties arise.

Planning proceeds relatively quickly because the initial assumptions will surely change as sprints deliver incremental functionality.

What happens during a sprint in Scrum?

A sprint produces a visible, usable, deliverable product that implements one or more user interactions with the system. The key idea behind each sprint is to deliver the valuable functionality.

Each product increment builds on previous increments. The goal is to complete tasks by the sprint’s delivery date. A sprint is time-boxed development, meaning that the end date for a sprint does not change. The team can reduce delivered functionality during the sprint, but the delivery date cannot change.

During the sprint, the team holds frequent (usually daily) Scrum meetings. These meetings address the observation under consideration. When the team comes together for a short, daily meeting, any slip is immediately obvious to everyone. The meetings involve all teammembers, including those who telecommute. The meetings serve a team-building purpose and bring in even remote contributors, making them feel a part of the group and making their work visible to the rest of the team.

Figure: Sprint meeting

How does Scrum work?

Scrum is a software development process for small teams. It is more effective for the teams that work independently. Well seasoned research in social dynamics supports this view. The phenomenon called social loafing, identified as early as 1927, empirically measured individual contribution to a group effort.

As in all projects, there must be an initial planning phase. During this phase, the project team must develop an architecture and identify a chief architect. During development, the team should be prepared to make changes to this architecture, but they need a plan, an architecture, and a chief architect at the start. The chief architect defines the development project’s vision based on this architecture and ensures that vision’s consistency throughout all the development phases.

After initial planning, a series of short development phases, or sprints, deliver the product incrementally. A sprint typically lasts one to four weeks. A closure phase usually completes product development.

The team tracks all currently identified tasks, capturing them in a list called the backlog. The backlog drives team activity. Before each sprint, the team updates the backlog and reprioritizes the tasks - each team signs up for a number of tasks and then executes a sprint. Individual team members agree to complete tasks they believe are feasible during each sprint. The team defines task granularity as appropriate, commonly specifying that a task must be completed in less than a week - larger tasks are more difficult to define and report.

During a sprint, no changes are allowed from outside the team.

Figure: Scrum Workflow

What is Scrum?

A scrum is a team of eight individuals in Rugby. Everyone in the pack acts together with everyone else to move the ball down the field. For those who know rugby, the image is clear. Teams work as tight, integrated units with each team member playing a well defined role and the whole team focusing on a single goal. In development teams, each team member must understand his or her role and the tasks for each increment. The entire team must have a single focus. The priorities must be clear. As we now describe, the Scrum development process facilitates this team focus.

Figure: Scrum in Rugby