SCRUM FRAMEWORK - Roles, Activities, and Artifacts

The purpose of this article is to provide an overview of the Scrum framework with main focus on its practices, including roles, activities, and artifacts.

Scrum is a framework for organizing and managing work. The Scrum framework is based on a set of values, principles, and practices that provide the foundation to which a company adds its peculiar implementation of engineering practices and specific approaches for realizing the Scrum practices. The outcome is a version of Scrum that is unique and specific, in order to have a process that works for us.

Scrum development efforts consist of one or more Scrum teams, each made up of three Scrum roles: Product owner, ScrumMaster, and the Development team.

• is the empowered central point of product leadership
• is the only authority responsible for what will be developed and in what order
• he maintains and communicates to all other participants a clear vision of what the Scrum team is trying to achieve
• as such, the product owner is responsible for the overall success of the solution being developed or maintained.

• helps everyone involved understand and embrace the Scrum values, principles, and practices
• acts as a coach, providing development process leadership
• as a facilitator, ScrumMaster helps the team resolve issues and make improvements to its use of Scrum
• is responsible for protecting the team from outside interference
• takes a leadership role in removing impediments that inhibit team productivity
• has no authority to exert control over the team, so this role is not the same as the traditional role of project manager or development manager. The Scrum-Master functions as a leader, not a manager.

Traditional software development consists of various job types, such as architect, programmer, tester, database administrator, UI designer, etc. Scrum defines a development team as a diverse, cross-functional collection of people who are responsible for designing, building, and testing the desired product.

• the development team self-organizes to determine the best way to accomplish the goal set out by the product owner
• is typically five to nine people in size; its members must collectively have all skills needed to produce good quality, working software.

Using Scrum, we always do the most valuable work first. The product owner is responsible for determining and managing the sequence of this work and communicating it in the form of a prioritized (or ordered) list known as the product backlog. On new-product development the product backlog items initially are features required to meet the product owner’s vision. For ongoing product development, the product backlog might also contain new features, changes to existing features, defects, needing repair, technical improvements, etc.

The product owner collaborates with internal and external stakeholders to gather and define the product backlog items. He then ensures that product backlog items Scrum Activities and Artifacts are placed in the correct sequence. Items can be added, deleted, and revised by the product owner as business conditions change.

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

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.

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 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.

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. “Done” means there is a high degree of confidence that all of the work necessary for producing good-quality features has been completed.

Team members define their own task-level work and then self-organize in any manner they feel is best for achieving the sprint goal.

Each day of the sprint, ideally at the same time, the development team members hold a timeboxed (15 minutes or less) daily scrum. This inspect-and adapt activity is sometimes referred to as the daily stand-up because of the common practice of everyone standing up during the meeting to help promote brevity.

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. 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.

Done

In Scrum, we refer to the sprint results as a potentially shippable product increment, meaning that whatever the Scrum team agreed to do is really done according to its agreed-upon definition of done.

At the end of the sprint there are two additional inspect-and-adapt activities. One is called the 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.

A successful review results in bidirectional information flow. The people who aren’t on the Scrum team get to sync up on the development effort and help guide its direction. At the same time, the Scrum team members gain a deeper appreciation for the business and marketing side of their product by getting frequent feedback on the convergence of the product toward delighted customers or users. The sprint review therefore represents a scheduled opportunity to inspect and adapt the product.

The second inspect-and-adapt activity at the end of the sprint is the sprint retrospective. Whereas the sprint review is a time to inspect and adapt the product, the sprint retrospective is an opportunity to inspect and adapt the process. 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.

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.

After the sprint retrospective is completed, the whole cycle is repeated again - starting with the next sprint-planning session, held to determine the current highest value set of work for the team to focus on.

Note: This article is inspired by the lecture of “ESSENTIAL SCRUM, A PRACTICAL GUIDE TO THE MOST POPULAR AGILE PROCESS", written by KENNETH S. RUBIN. I strongly recommend this book.

Read more about the advantages of working with dedicated teams for software development outsourcing!