Scrum is an agile way to manage a project, usually software development. Agile software development with Scrum is often perceived as a methodology; but rather than viewing Scrum as methodology, think of it as a framework for managing a process. It is designed for teams of three to nine developers who break their work into actions that can be completed within timeboxed iterations, called sprints (30 days or less, most commonly two weeks) and track progress and re-plan in 15-minute stand-up meetings, called daily scrums
Scrum has three roles: Product Owner, Scrum Master, and Team.
Product Owner: The Product Owner should be a person with vision, authority, and availability. The Product Owner is responsible for continuously communicating the vision and priorities to the development team.
It’s sometimes hard for Product Owners to strike the right balance of involvement. Because Scrum values self-organization among teams, a Product Owner must fight the urge to micro-manage. At the same time, Product Owners must be available to answer questions from the team.
Scrum Master: The Scrum Master acts as a facilitator for the Product Owner and the team. The Scrum Master does not manage the team. The Scrum Master works to remove any impediments that are obstructing the team from achieving its sprint goals. This helps the team remain creative and productive while making sure its successes are visible to the Product Owner. The Scrum Master also works to advise the Product Owner about how to maximize ROI for the team.
Team: According to Scrum’s founder, “the team is utterly self managing.” The development team is responsible for self organizing to complete work. A Scrum development team contains about seven fully dedicated members (officially 3-9), ideally in one team room protected from outside distractions. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. The team has autonomy and responsibility to meet the goals of the sprint.
A sprint (or iteration) is the basic unit of development in Scrum. The sprint is a timeboxed effort; that is, it is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month, with two weeks being the most common.
Each sprint starts with a sprint planning event that aims to define a sprint backlog, identify the work for the sprint, and make an estimated forecast for the sprint goal. Each sprint ends with a sprint review and sprint retrospective, that reviews progress to show to stakeholders and identify lessons and improvements for the next sprints.
At the beginning of a sprint, the scrum team holds a sprint planning event to:
- Mutually discuss and agree on the scope of work that is intended to be done during that sprint
- Select product backlog items that can be completed in one sprint
- Prepare a sprint backlog that includes the work needed to complete the selected product backlog items
- The recommended duration is four hours for a two-week sprint
- Once the development team has prepared their sprint backlog, they forecast (usually by voting) which tasks will be delivered within the sprint.
A daily scrum in the computing room. This centralized location helps the team start on time.
Each day during a sprint, the team holds a daily scrum (or stand-up) with specific guidelines:
- All members of the development team come prepared. The daily scrum:
- starts precisely on time even if some development team members are missing
- should happen at the same time and place every day
- is limited (timeboxed) to fifteen minutes
- Anyone is welcome, though only development team members should contribute.
- During the daily scrum, each team member typically answers three questions:
- What did I complete yesterday that contributed to the team meeting our sprint goal?
- What do I plan to complete today to contribute to the team meeting our sprint goal?
- Do I see any impediment that could prevent me or the team from meeting our sprint goal?
Any impediment (e.g., stumbling block, risk, issue, delayed dependency, assumption proved unfounded) identified in the daily scrum should be captured by the scrum master and displayed on the team’s scrum board or on a shared risk board, with an agreed person designated to working toward a resolution (outside of the daily scrum). No detailed discussions should happen during the daily scrum.
At the end of a sprint, the team holds two events: the sprint review and the sprint retrospective.
At the sprint review, the team:
- Reviews the work that was completed and the planned work that was not completed
- Presents the completed work to the stakeholders
- The team and the stakeholders collaborate on what to work on next
Guidelines for sprint reviews:
- Incomplete work cannot be demonstrated
- The recommended duration is two hours for a two-week sprint (proportional for other sprint durations)
At the sprint retrospective, the team:
- Reflects on the past sprint
- Identifies and agrees on continuous process improvement actions
Guidelines for sprint retrospectives:
- Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
- The recommended duration is one-and-a-half hours for a two-week sprint (proportional for other sprint durations)
- This event is facilitated by the scrum master
The following activities are commonly done, although not considered by all as a core part of Scrum:
Backlog refinement (once called backlog grooming) is the ongoing process of reviewing product backlog items and checking that they are appropriately prioritised and prepared in a way that makes them clear and executable for teams once they enter sprints via the sprint planning activity. Product backlog items may be broken into multiple smaller ones; acceptance criteria may be clarified; and dependencies, investigation, and preparatory work may be identified and agreed as technical spikes.
Although not originally a core Scrum practice, backlog refinement has been added to the Scrum Guide and adopted as a way of managing the quality of product backlog items entering a sprint, with a recommended investment of up to 10% of a team’s sprint capacity.
The backlog can also include technical debt (also known as design debt or code debt). This is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.
Cancelling a sprint
The product owner can cancel a sprint if necessary.The product owner may do so with input from the team, scrum master or management. For instance, management may wish the product owner to cancel a sprint if external circumstances negate the value of the sprint goal. If a sprint is abnormally terminated, the next step is to conduct a new sprint planning, where the reason for the termination is reviewed.