At the beginning of 1990, when Scrum was in its infancy, organizations started using the Scrum framework to build the products using various processes and techniques.
The Scrum framework consists of the Scrum teams with associated Scrum Roles, Scrum Ceremonies/Events, Artifacts scrum, and Scrum rules. Each component within this framework has specific grounds and is a key factor to Scrum’s success, whereas the Scrum rules tie the ceremonies, roles, and artifacts together to govern the relationships between them.
In this blog, we will look into all these components in detail.
Brief Introduction to Scrum Framework
Scrum is a framework designed to deliver software products that comprise three roles, three artifacts, and Five events.
These basic elements provide a structure to manage the decisions, risks, actions, and uncertainties that come with building and maintaining a software product. Scrum is deliberately incomplete, in that it goes no further than specifying who is accountable for what, with a basic structure to ask the right questions. Once established, as Scrum team will complete the process by adding the business- and technology-specific processes that make sense for their work. Over time, a mature team will evolve a bespoke process based around the core Scrum framework that is as efficient and effective as their skills and imaginations allow.
Image Source: Google
Read: Scrum Master Interview Questions
Scrum Roles Defined
The fundamental unit of Scrum is a small team of people, a Scrum Team that consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
- Scrum Teams are cross-functional which implies that the members have all the skills necessary to create value for each Sprint.
- They are self-managing, meaning they internally decide who does what, when, and how.
- The team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.
- They are structured and empowered by the organization to manage their own work.
- Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.
Image Source: Google
Read: Project Manager vs Scrum Master vs Product Owner Overview
1.) Product Owner
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team for which the method may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is also accountable for effective Product Backlog management, including:
- Developing and explicitly communicating the Product Goal
- Creating and clearly communicating Product Backlog items
- Ordering Product Backlog items
- Ensuring that the Product Backlog is transparent, visible, and understandable
The Product Owner may do the above work or delegate the responsibility to others but in either case, the product owner is accountable for it.
Note: The Product Owner is one person, not a committee!!
2.) Scrum Master – what is part of the role of the scrum master
The Scrum Master is accountable for establishing Scrum by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization. He is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework. Scrum Masters are true leaders who serve the Scrum Team and the larger organization.
The Scrum Master serves the Scrum Team in several ways, including:
- Coaching the team members in self-management and cross-functionality;
- Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
- Causing the removal of impediments to the Scrum Team’s progress; and,
- Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.
The Scrum Master also serves the Product Owner in several ways, including:
- Help in finding techniques for effective Product Goal definition and Product Backlog management
- Help the Scrum Team understand the need for clear and concise Product Backlog items
- Help establish empirical product planning for a complex environment
- Facilitate stakeholder collaboration as requested or required
The Scrum Master serves the organization in the following ways:
- Leading, training, and coaching the organization in its Scrum adoption
- Planning and advising Scrum implementations within the organization
- Help employees and stakeholders understand and enact an empirical approach for complex work
- Removing barriers between stakeholders and Scrum Teams
Read the blog to know more about Scrum Master Roles & Responsibilities
3.) Developers
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment for each Sprint.
The specific skills needed by the Developers are often broad and vary with the domain of work. However, the Developers are always accountable for:
- Creating a plan for the Sprint, the Sprint Backlog
- Instilling quality by adhering to a Definition of Done (DoD)
- Adapting their plan each day toward the Sprint Goal
- Holding each other accountable as professionals
Read More: About Agile SDLC.
Scrum Events
The Sprint is a container for all other events. Each event in Scrum is a formal opportunity to inspect and adapt artifacts scrum. These events are specifically designed to enable the transparency required. Failure to operate any events as prescribed results in lost opportunities to inspect and adapt. Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.
Optimally, all events are held at the same time and place to reduce complexity.
- The Sprint
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
1.) The Sprint
Sprints are the heartbeat of Scrum, where ideas are turned into value. These are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint. All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints. A Sprint could be canceled if the Sprint Goal becomes obsolete and only the Product Owner has the authority to cancel the Sprint.
2.) Sprint Planning
Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team. The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Scrum Team may also invite other people to attend Sprint Planning to provide advice. Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
In the Sprint Planning the following topics are addressed:
- Why is this Sprint valuable?
- What can be done this Sprint?
- How will the chosen work get done?
3.) Daily Scrum
The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers. Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.
Read: Scrum User Story
4.) Sprint Review
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
It is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint.
5.) Sprint Retrospective
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
Check Out: Agile vs Scrum, to know the major differences between them.
Scrum Artifacts
Scrum’s artifacts represent work or value. They are designed to maximize the transparency of key information so that everyone inspecting them has the same basis for adaptation.
Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:
- For the Product Backlog, it is the Product Goal.
- For the Sprint Backlog, it is the Sprint Goal.
- For the Increment, it is the Definition of Done.
These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and its stakeholders.
Scrum Artifacts List
1.) Product Backlog
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
Product Backlog items that can be done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.
Image Source: Google
Read: Scrum vs Kanban
2.) Sprint Backlog
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.
Image Source: Google
3.) Increment
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.
Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.
Work cannot be considered part of an Increment unless it meets the Definition of Done (DoD).
Image Source: Google
Hope this article helps you to get a clear concept of the three core components of the scrum framework.
Next Task for You
If you are considering in-depth learning about Scrum Master Certification in the upcoming days, join our Free Class and don’t miss an opportunity to attend a Free Class and gain a plethora of insights about Certified Scrum Master.
The post Scrum Roles & Scrum events | Scrum Artifacts : Scrum Framework Overview appeared first on Cloud Training Program.