Now that we have covered the framework’s foundational aspects let’s get to the elements that help you practically implement Scrum. As people are at the center of every agile, let’s start with discussing the accountabilities on Scrum Teams and what each of them do.
There are many exciting aspects of a Scrum team. Let’s start with accountabilities.
Earlier, the Scrum Guide used the word “roles” to define the constituents of the team. There were three roles, Scrum Master, Product Owner, and the Development Team.
The use of the term role led to confusing the work done as part of the team as designations or job activities. While there is nothing wrong with using Scrum Master as the designation, from an organization’s perspective, the tasks performed by the person designated as the Scrum Master can be beyond the responsibilities described by the framework.
The new term, accountability, ties in closely with the commitment. A Scrum team now has three accountabilities, Scrum Master, the product owner, and developers.
The change from “development team” to “developers” is also significant. The term “Development Team” may allude to a separate entity within the team. However, this new term underlines that a Scrum team is one cohesive unit committed to and accountable for the outcomes.
Table of Contents
What are these outcomes?
The core outcome is the product goal. Therefore, the team is accountable for the product goal. Till it is either achieved or abandoned by the business, the team commits to and focuses on one goal at one time.
The second outcome is the Sprint goal, and the third outcome is the product increment that conforms to the definition of done.
We will talk more about these outcomes when we discuss Scrum artifacts. But each of the scrum team members is accountable for these outcomes.
Scrum Teams: Key Characteristics
A Cross-functional team should have all skills required to create the sprint value. Of course, Cross-functionality does not mean that every individual should have all the skills required to generate a valuable increment. However, together the Agile team should do that by completing the user stories selected for this iteration.
The developers decide who does what, when, and how. While they are open to suggestions generally, the agile team takes the final decision.
The recommended Scrum team size is a maximum of 10 people. If there are more, instead of creating larger teams, break up into multiple teams that share the same product goal, product backlog, and the product owner. Smaller teams are recommended given the effectiveness of communication, but too small a team may not create a valuable increment. Hence, the team should be appropriately sized but less than 10.
The team performs every activity required to turn up a product increment at the end of every sprint. These activities include customer and stakeholder collaboration, product development, testing & quality assurance, roll-out, and any maintenance. Thus, some members might be involved in limited activities within the team, while others might be involved in all activities. Plus, it is possible that even the persons with accountabilities of Scrum Master and Product Owner to perform developer activities.
The focus of the team is to achieve sustainable peace, which induces focus and consistency.
The Scrum team together also creates the “Definition of Done” (DoD). The DoD will reflect the organizational standards as well as the requirements defined by the Scrum team. If multiple Scrum teams are working on a single product, the DoD of the teams should be crafted to make the collective output of the teams acceptable and valuable. The developers must produce enough work to meet the DoD during each sprint.
The Product Owner Accountabilities
One of the crucial roles in a scrum team is that of the product owner. The product owner ensures that what is built is truly valuable to the business and made the right way. The product owner also works with the team to optimize the value of their work in the form of the valuable increment they produce every sprint.
It is the product owner, an individual, who decides what shape the product will take from a long-term, strategic perspective. While the inputs can come from many sources, including stakeholders, customers, and even the scrum team, a single person must perform the PO accountabilities. In addition, the external business environment, government legislation, or compliance requirements can also necessitate changes or additions to the product. The product owner evaluates all such needs, takes cognizance of all inputs, and builds the product backlog.
The product goal is the guiding factor for the PO to decide what is worth building and what is not. Therefore, the product backlog should contribute directly to the product goal. The PO’s responsibility is to ensure that the items that don’t contribute to the product goal are not part of the product backlog.
Once all the required work for the product is in the product backlog, the PO is accountable for prioritizations of these product backlog items. Again, the inputs may come from many sources. The PO can take help from the developers, but the ultimate control, ownership, and responsibility of prioritization and the product backlog rest with the PO.
One of the primary responsibilities of the PO is to set the sprint goal. The sprint goal is the common goal that the Scrum team commits to achieve during a sprint. This goal is the result of prioritization by the PO.
The product owner is also responsible for ensuring that the product backlog items are clear to everyone, especially the developers. The PO must ensure that the developer knows what to build and how it contributes to the product goal. The product owner is the person who knows the most about the progress towards the product goal by closely aligning and collaborating with the developers.
The product backlog is visible to everyone in the organization, along with the prioritization. Additionally, Sprint Review provides another opportunity to everyone outside the Scrum team to inspect the product increment. This approach allows for transparent ways to ensure that the development is following the product goal.
The product owner is also responsible for deciding if the sprint needs to be canceled or terminated. To make this decision, the PO must first ascertain that the sprint goal has become obsolete.
The Developer Accountabilities
While the Product Owner is the product visionary, the Developers give shape to that vision. The primary accountability of the developers is to convert the product backlog items (PBIs) into product increments. Developers undertake many activities that help them fulfill this primary objective.
The very first step for the developers is to understand the long-term and the short-term vision. While Scrum Guide doesn’t list product backlog refinement as an explicit event, it is a helpful tool for the developers. The refinement provides an opportunity for the developers to get sufficient clarity on the PBIs from the PO.
When the developers are clear about high-priority items, they use this clarity to plan the sprint. However, as with other Agile methods, the planning with Scrum differs drastically from the traditional planning methods. That’s because of the difference in how we estimate the work in Scrum.
While Scrum Guide is silent on estimation, the story points, relative sizing, and velocity-driven planning as well-entrenched in how Scrum teams work, developers use the understanding to assign a story point, measuring how difficult or easy the story is compared to other tasks. Then based on the available capacity, the developers pull the stories from the product backlog to the sprint backlog during Sprint Planning.
The developers are also accountable for maintaining transparency about the progress and impediments. Teams achieve such transparency through a variety of events, tools, and techniques. For example, the Daily Scrum is when an individual can transparently bring out these aspects in the open. Depending upon the attendance in the daily Scrum, the team or even other stakeholders can become aware of the progress and challenges.
Sprint Reviews are another even when the progress is transparent for a broader set of people, including the team and stakeholders. The developers are responsible for managing the progress of the work during the sprint.
Developers are also accountable to continuously improve how they work to make product increments more efficient and effective. A Sprint Retrospective is the critical event for identifying the scope of such improvements.
Developers should plan the improvements into the work as soon as possible, but generally in a way that doesn’t harm the sprint goal. It is entirely up to the development team to prioritize, plan, and implement such improvements into their work.
The developers are also responsible for any changes to the sprint backlog. Three types of changes can occur, emergence, addition, or deletion. The team should evaluate any decision involving such changes against the need to achieve the sprint goal. For example, if the development team identifies a Product Backlog Item (PBI) that is no longer required to meet the sprint goal, the team can remove such items. However, for any such decision, developers should consider involving the PO.
The Developers create the Sprint Backlog, reflecting all work required to meet the Definition of Done and produce a valuable increment at the end of the sprint. The Sprint planning is done collaboratively. The Developers also have all the skills they need to create a working product increment. They also adapt the sprint plan daily as the work progresses and more details become available. Developers can also make appropriate adjustments to the Sprint plan in consultation with the product owner. The developers, collectively, are responsible for every Product Backlog Item (PBI) considered in the Sprint Backlog. So, while each team member would work on the user stories and PBIs they have pulled from the Sprint Backlog, the team is accountable for the completion.
In general, it is helpful to create long-lasting Scrum teams where the members are permanent. However, practically there would be a need from time to time. When such changes happen, the developers see a dip in the team productivity initially. However, over time, the velocity and productivity should again stabilize.
Scrum Master
The Scrum Master interacts and influences the entire organization, the Product Owner, and the Scrum team in different ways.
From the organizational perspective, the Scrum master helps with the awareness and adoption of Scrum effectively. The SM influences such adoption through a variety of approaches. They will need to coach, train, and mentor stakeholders, including management, and plan and execute the adoption. This exercise starts with explaining the empirical approach of transparency, inspection, and adoption.
Scrum Master is the guide, coach, and conscience keeper of the scrum team. The primary accountability of the Scrum Master is to ensure that the Scrum team understands and adheres to the spirit and letter of the Scrum Framework. In addition, the SM ensures that Agile Principles, values, and practices are understood and followed by everyone.
The Scrum Master also ensures and facilitates Sprint Planning Meeting, Daily Scrum, Sprint Reviews, and Sprint Retrospectives effectively. In addition, the SM also ensures that these events are completed within the prescribed timeboxes.
For Daily Scrum, the SM doesn’t need to be present, nor does the PO. The Daily Scrum is for Developers. However, the Scrum Master must ensure that the Daily Scrum happens effectively and within the timebox. They must also ensure that the Daily Scrum is not turned into a status meeting but is used to generate the plan for the day ahead. The SM also protects the Daily Scrum from outside influences.
The Scrum Master also works with the PO to facilitate effective prioritization of the Product Backlog Items. They help the PO with the tools and techniques to effectively define product and sprint goals and manage the product backlog. By working with the PO and Developers, the SM ensures that clear and concise PBIs add value to the product and the developers’ work.
The Scrum Master also acts as a bridge between stakeholders and the Scrum team. They facilitate open and productive collaboration between stakeholders and team by removing the barriers to such communication. The SM also helps PO collaborate with stakeholders to ensure the alignment between the business, customer needs, and the Scrum team’s product.
Management
The Scrum teams don’t operate in isolation. They are part of the enterprise, and thus, many factors outside the team’s purview influence it. Since the management shapes these external factors, it is critical to understand their role in a Scrum team’s success.
While the Scrum Master and the Product Owner are the primary roles that interact with management, the developers may interact with them formally during the Sprint Review. In addition, management and other stakeholders participate in the Sprint Review to inspect the product increment and suggest the best way forward. These stakeholders can also attend the daily Scrum, although they cannot participate.
Through these events, the management understands the progress of the product development. They can also form an understanding of the processes, including the scope of improvements.
Through such understanding, the management can prove to be instrumental in the success of the Scrum team. They assist the Scrum Master in organizational change management to support empirical thinking and adopt Agile values, principles, and practices. They also help the Scrum Master remove business impediments for the teams.
The management also helps the PO with insights about building a great product. Such insights can come from their knowledge of the competitive environment, compliance and regulatory requirements, and experience.
The management also helps an environment of psychological safety, open collaboration, and bottom-up intelligence. Such an environment is conducive to the Scrum team’s self-organization, ensuring great success for the team.
Featured Image: Photo by Mitchell Luo on Unsplash
