Understanding Scrum Framework

Scrum is an agile approach for developing products and services. With an agile approach, you begin by creating a product backlog—a prioritized list of the features and other capabilities needed to develop a successful product. Guided by the product backlog, you always work on the most important or highest priority items first. When you run out of resources (such as time), any work that didn’t get completed will be of lower priority than the completed work.

The work itself is performed in short, timeboxed iterations or sprints, which usually range from a week to a calendar month in length. During each iteration, a self-organizing, cross-functional team does all of the work such as designing, building, and testing required to produce completed, working features that could be put into production.

Typically the amount of work in the product backlog is much greater than can be completed by a team in one short-duration iteration or sprint. So, at the start of each sprint, the team plans which high-priority subset of the product backlog to create in the upcoming sprint which can be termed as Sprint Backlog. At the end of each sprint, the team should have a potentially shippable product (or increment of the product), one that can be released if appropriate. If releasing after each sprint isn’t appropriate, a set of features from multiple sprints can be released together.

After reading the above.. you must have come across some new terms such as product backlog, iterations, sprints, sprint backlogs, increment etc. Let us understand there terms in some more details in the remaining part of this article.

Scrum framework or practice is nothing but a set of roles, activities, artifacts, and their associated rules as given in below picture.

Scrum Roles:

Product Owner:

The product owner is responsible for what will be developed and in what order. The product owner maintains and communicates to all other participants a clear vision of what the Scrum team is trying to achieve. The product owner actively collaborates with the ScrumMaster and development team and must be available to answer questions soon after they are posed.

Scrum Master:

The ScrumMaster helps everyone involved understand and embrace the Scrum values, principles, and practices. He or She functions as a leader, not a manager. This role is not the same as the traditional role of project manager or development manager. The ScrumMaster helps the team resolve issues and make improvements to its use of Scrum. He or she is also responsible for protecting the team from outside interference and takes a leadership role in removing impediments that inhibit team productivity.

Development Team:

Development team, which is simply a diverse, cross-functional collection of people who are responsible for designing, building, and testing the desired product. The team self-organizes to determine the best way to accomplish the goal set out by the product owner. The development team is typically five to nine people in size; its members must collectively have all of the skills needed to produce good quality, working software.

Scrum Activities/Artifacts:

Product Backlog and Grooming:

The product owner collaborates with internal and external stakeholders to gather and define the product backlog items. He then ensures that product backlog items are placed in the correct sequence (using factors such as value, cost, knowledge, and risk) so that the high-value items appear at the top of the product backlog and the lower-value items appear toward the bottom. The product backlog is a constantly evolving artifact. Items can be added, deleted, and revised by the product owner as business conditions change, or as the Scrum team’s understanding of the product grows (through feedback on the software produced during each sprint). Before we finalize prioritizing, ordering, or otherwise arranging the product backlog, we need to know the size of each item in the product backlog. Size equates to cost, and product owners need to know an item’s cost to properly determine its priority. In practice, many teams use a relative size measure such as story points or ideal days. A relative size measure expresses the overall size of an item in such a way that the absolute value is not considered, but the relative size of an item compared to other items is considered.

Overall the activity of creating and refining product backlog items, estimating them, and prioritizing them is known as Grooming.

Sprints:

In Scrum, work is performed in iterations or cycles of up to a calendar month called sprints The work completed in each sprint should create something of tangible value to the customer or user. Sprints are timeboxed so they always have a fixed start and end date, and generally they should all be of the same duration. A new sprint immediately follows the completion of the previous sprint.

Sprint Planning:

A product backlog may represent many weeks or months of work, which is much more than can be completed in a single, short sprint. To determine the most important subset of product backlog items to build in the next sprint, the product owner, development team, and ScrumMaster perform sprint planning. During sprint planning, the product owner and development team agree on a sprint goal that defines what the upcoming sprint is supposed to achieve. Using this goal, the development team reviews the product backlog and determines the high priority items that the team can realistically accomplish in the upcoming sprint while working at a sustainable pace, to acquire confidence in what it can get done, many development teams break down each targeted feature into a set of tasks. The collection of these tasks, along with their associated product backlog items, forms a second backlog called the Sprint Backlog.

The development team then provides an estimate (typically in hours) of the effort required to complete each task. Breaking product backlog items into tasks is a form of design and just-in-time planning for how to get the features done. Most Scrum teams performing sprints of two weeks to a month in duration try to complete sprint planning in about four to eight hours.

Once the Scrum team finishes sprint planning and agrees on the content of the next sprint, the development team, guided by the ScrumMaster’s coaching, performs all of the task-level work necessary to get the features done, where “done” means there is a high degree of confidence that all of the work necessary for producing good-quality features has been completed.

Daily Scrum/Stand-up meeting:

Each day of the sprint, ideally at the same time, the development team members hold a timeboxed (15 minutes or less) daily scrum (see Figure 2.11). This inspect-and adapt activity is sometimes referred to as the daily stand-up.

A common approach to performing the daily scrum has the ScrumMaster facilitating and each team member taking turns answering three questions for the benefit of the other team members:

• What did I accomplish since the last daily scrum?
• What do I plan to work on by the next daily scrum?
• What are the obstacles or impediments that are preventing me from making progress?

By answering these questions, everyone understands the big picture of what is occurring, how they are progressing toward the sprint goal, any modifications they want to make to their plans for the upcoming day’s work, and what issues need to be addressed. The daily scrum is essential for helping the development team manage the fast, flexible flow of work within a sprint.

The daily scrum is not a problem-solving activity. Rather, many teams decide to talk about problems after the daily scrum and do so with a small group of interested people.

Sprint Review:

The goal of this activity is to inspect and adapt the product that is being built. Critical to this activity is the conversation that takes place among its participants, which include the Scrum team, stakeholders, sponsors, customers, and interested members of other teams. The conversation is focused on reviewing the just-completed features in the context of the overall development effort. Everyone in attendance gets clear visibility into what is occurring and has an opportunity to help guide the forthcoming development to ensure that the most business-appropriate solution is created.

Sprint Retrospective:

During the sprint retrospective the development team, ScrumMaster, and product owner come together to discuss what is and is not working with Scrum and associated technical practices. The focus is on the continuous process improvement necessary to help a good Scrum team become great. At the end of a sprint retrospective the Scrum team should have identified and committed to a practical number of process improvement actions that will be undertaken by the Scrum team in the next sprint.

This Article described core Scrum practices, focusing on an end-to-end description of the Scrum framework’s roles, activities, and artifacts. Hope you enjoyed reading the article. Do share your comments and feedback. This article has been written basis the knowledge i have gained reading Essential Scrum by Kenneth S. Rubin and Project Management Body of Knowledge(PMBOK) 6.