Scrum is an iterative and incremental framework for managing product development. It defines “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal”, challenges assumptions of the “traditional, sequential approach” to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines involved.
Many of the terms used in Scrum (e.g., scrum master) are typically written with leading capitals (i.e., Scrum Master) or as conjoint words written in camel case (i.e., ScrumMaster).
While the trademark on the term Scrum itself has been allowed to lapse, so that it is deemed as owned by the wider community rather than an individual, the leading capital is retained—except when used with other words (as in daily scrum or scrum team).
Scrum is considered to be a lightweight agile method that uses practices, events, roles, artifacts, and rules for project execution. This method is supported by three “pillars” that guide all facets of the Scrum project:
- Transparency: Everything on a Scrum project is visible to all who have a stake in the outcome.
- Inspection: The Scrum project is inspected on a regular basis to ensure that progress is being made toward the goals and objectives.
- Adaptation: Processes are adjusted as needed when problems or undesirable issues present themselves.
The benefits of Scrum include but are not limited to the following:
- The process is incremental and iterative.
- Requirements are permitted to change over a period of time.
- The end users are actively involved throughout the project.
- The process is straightforward and uncomplicated.
Possible weaknesses of Scrum methods include:
- In the event that a team member leaves the project, the impact is significant.
- The Scrum project requires experienced team members. Inexperienced team members can lead to project delays.
- The method is very informal.
A typical Scrum project has six to ten team members. This agile method is more suited to small teams, however, it can be adapted to large teams as well. Companies and projects that are team, value, and customer oriented are the best candidates for Scrum methods.
The primary difference between the defined (waterfall, spiral and iterative) and empirical (SCRUM) approach is that The SCRUM approach assumes that the analysis, design, and development processes in the Sprint phase are unpredictable. A control mechanism is used to manage the unpredictability and control the risk. Flexibility, responsiveness, and reliability are the results.
Roles
There are three core roles in the Scrum framework. These are ideally co-located to deliver potentially shippable product increments every sprint. Together these three roles form the scrum team. While many organizations have other roles involved with defining and delivering the product, Scrum defines only these three.
Product owner –
The product owner represents the product’s stakeholders and the voice of the customer; and is accountable for ensuring that the team delivers value to the business. The product owner defines the product in customer-centric terms (typically user stories), adds them to the product backlog, and prioritizes them based on importance and dependencies. Scrum teams should have one product owner.
Communication is a core responsibility of the product owner. The ability to convey priorities and empathize with team members and stakeholders is vital to steer product development in the right direction. The product owner role bridges the communication gap between the team and its stakeholders, serving as a proxy for stakeholders to the team and as a team representative to the overall stakeholder community.
As the face of the team to the stakeholders, the following are some of the communication tasks of the product owner to the stakeholders:
- demonstrates the solution to key stakeholders who were not present at a sprint review;
- defines and announces releases;
- communicates team status;
- organizes milestone reviews;
- educates stakeholders in the development process;
- negotiates priorities, scope, funding, and schedule;
- ensures that the product backlog is visible, transparent, and clear.
Empathy is a key attribute for a product owner to have—the ability to put one’s self in another’s shoes. A product owner converses with different stakeholders, who have a variety of backgrounds, job roles, and objectives.
A product owner’s ability to communicate effectively is also enhanced by being skilled in techniques that identify stakeholder needs, negotiate priorities between stakeholder interests, and collaborate with developers to ensure effective implementation of requirements.
Development team –
The development team is responsible for delivering potentially shippable product increments every sprint (the sprint goal).
The team has from three to nine members who carry out all tasks required to build the product increments (analysis, design, development, testing, technical writing, etc.). Although there will be several disciplines represented in the team, its members are referred to generically as developers. To avoid potential confusion that this only refers to programmers, some organizations call this a delivery team and its members just team members.
Scrum master –
Scrum is facilitated by a scrum master, who is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables. The scrum master is not a traditional team lead or project manager but acts as a buffer between the team and any distracting influences.The role has also been referred to as a team facilitator or servant-leader to reinforce these dual perspectives.
The core responsibilities of a scrum master include (but are not limited to):
- Helping the product owner maintain the product backlog in a way that ensures the needed work is well understood so the team can continually make forward progress
- Helping the team to determine the definition of done for the product, with input from key stakeholders
- Coaching the team, within the Scrum principles, in order to deliver high-quality features for its product
- Promoting self-organization within the team
- Helping the scrum team to avoid or remove impediments to its progress, whether internal or external to the team
- Facilitating team events to ensure regular progress
- Educating key stakeholders in the product on Scrum principles
- Coaching the development team in self-organization and cross-functionality
One of the ways the scrum master role differs from a project manager is that the latter may have people management responsibilities and the scrum master does not. Scrum does not formally recognise the role of project manager, as traditional command and control tendencies would cause difficulties.
Workflow
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.
Scrum emphasizes working product at the end of the sprint that is really done. In the case of software, this likely includes that the software has been fully integrated, tested, and documented, and is potentially shippable.
Sprint planning – 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 (pro-rata for other sprint durations)
- During the first half, the whole scrum team (development team, scrum master, and product owner) selects the product backlog items they believe could be completed in that sprint
- During the second half, the development team identifies the detailed work (tasks) required to complete those product backlog items; resulting in a confirmed sprint backlog
- Once the development team has prepared their sprint backlog, they forecast (usually by voting) which tasks will be delivered within the sprint.
Daily scrum –
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.
Sprint review and retrospective – 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 (a.k.a. the demo)
- The team and the stakeholders collaborate on what to work on next
Artifacts
Product backlog – The product backlog comprises an ordered list of product requirements that a scrum team maintains for a product. The format of product backlog items varies, common formats include user stories, use cases, or any other requirements format the team finds useful. These will define features, bug fixes, non-functional requirements, etc.—whatever must be done to successfully deliver a viable product. The product owner prioritizes product backlog items (PBIs) based on considerations such as risk, business value, dependencies, size, and date needed.
The product backlog:
- Captures requests to modify a product—including new features, replacing old features, removing features, and fixing issues
- Ensures the development team has work that maximizes the business benefit to the product owner
Management – A product backlog, in its simplest form, is merely a list of items to work on. Having well-established rules about how work is added, removed and ordered helps the whole team make better decisions about how to change the product.
The product owner prioritizes product backlog items based on which are needed soonest. The team then chooses which items they can complete in the coming sprint. On the scrum board, the team moves items from the product backlog to the sprint backlog, which is the list of items they will build.
Sprint backlog – The sprint backlog is the list of work the development team must address during the next sprint. The list is derived by the scrum team progressively selecting product backlog items in priority order from the top of the product backlog until they feel they have enough work to fill the sprint. The development team should keep in mind its past performance assessing its capacity for the newsprint, and use this as a guidelines of how much ‘effort’ they can complete.
Product increment – The increment (or potentially shippable increment, PSI) is the sum of all the product backlog items completed during a sprint, integrated with the work of all previous sprints. At the end of a sprint, the increment must be complete, according to the scrum team’s definition of done (DoD), fully functioning, and in a usable condition regardless of whether the product owner decides to actually release it.
Sprint burn-down chart – The sprint burn-down chart is a public displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. The horizontal axis of the sprint burn-down chart shows the days in a sprint, while the vertical axis shows the amount of work remaining each day (typically representing estimate of hours of work remaining).\
Release burn-up chart – A sample burn-up chart for a release, showing scope completed each sprint
The release burn-up chart is a way for the team to provide visibility and track progress toward a release. Updated at the end of each sprint, it shows progress toward delivering a forecast scope. The horizontal axis of the release burn-up chart shows the sprints in a release, while the vertical axis shows the amount of work completed at the end of each sprint (typically representing cumulative story points of work completed).
Definition of Done (DoD) – The exit-criteria to determine whether a product backlog item is complete. In many cases the DoD requires that all regression tests be successful. The definition of done may vary from one scrum team to another, but must be consistent within one team.
Velocity – The total effort a team is capable of in a sprint. The number is derived by evaluating the work (typically in user story points) completed in the last sprint. The collection of historical velocity data is a guideline for assisting the team in understanding how much work they can likely achieve in a future sprint.
Spike – A time-boxed period used to research a concept or create a simple prototype. Spikes can either be planned to take place in between sprints or, for larger teams, a spike might be accepted as one of many sprint delivery objectives. Spikes are often introduced before the delivery of large or complex product backlog items in order to secure budget, expand knowledge, or produce a proof of concept.
Like other agile methods, effective adoption of Scrum can be supported through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the sprint backlog. There are also open-source and proprietary software packages for Scrum—which are either dedicated to product development using the Scrum framework, or support multiple product development approaches including Scrum.
Other organizations implement Scrum without software tools, and maintain their artifacts in hard-copy forms such as paper, whiteboards, and sticky notes.
