The Scrum team consists of 3 accountabilities, Developers, Product Owner, and Scrum Master.
Developers are accountable for building and delivering a quality working Product Increment at the end of each Sprint. They are a small group, typically 3 to 9 members that are cross-functional and self-organizing.
Developers are cross-functional to remove bottlenecks and dependencies. Developers on a Scrum team have all the necessary skills to turn a concept or idea into a working product without any hand-offs to another team (concept to cash). All the skills from analysis, design, architecture, data modeling, coding, testing, deployment, etc. are available on the team. To enable cross-functionality, individual team members need to work on their t-shaped skills or m-shaped skills. Each team member has deep expertise in 1 area and works on broadening their expertise in 1 or 2 other areas so that they can help their teammates when needed. Team members won’t be able to do the heavy lifting in areas outside their expertise, but they will be knowledgeable enough to finish something that the expert started so that the team keeps making forward progress toward their goals.
Developers work on small Scrum teams to maintain good interactions and communications. Too few team members and they won’t have all the necessary skills to deliver a Product Increment. Too many team members and they won’t have good team interactions, collaboration, and communication.
Developers are also self-organizing. Developers decide how to do the work, how long it’s going to take, how much of it they can do in each Sprint, and who is going to work on what. Developers determine how best to accomplish the Sprint Goal, task out their work, estimate it, and assign themselves work. Developers are the ones closest to the work and thus know best how to accomplish it.
Developers in Scrum are stable and long-lived. Team members don’t get swapped in and out from Sprint to Sprint. The team members stay together for an extended period of time so that they grow together and develop strong team dynamics, build trust, and become high performing.
Everyone that builds the product increment is referred to as a Developer. Developer does not equal programmer in Scrum. There are no testers, no analysts, no architects, and no programmers. It’s just Developers with cross-functional skills like testing, analysis, architecture, programming, etc. There are no sub-teams of Developers. Again, it’s just Developers to encourage the idea that they are all in this together. It’s not about the individual and finishing individual tasks. It’s about the team with mutual accountability for accomplishing the Sprint Goal and delivering a quality working Product Increment at the end of each Sprint. What matters is accomplishing goals and delivering a quality Product Increment, and everyone is accountable for that irrespective of their primary skill set.
The Product Owner is accountable for delivering a valuable Product Increment. The Product Owner does that by ensuring that Developers are working on the most valuable items. The Product Owner is 1 person and not a committee. The organization empowers the Product Owner to listen to the market, the customers, the buyers, the users, the developers, and the stakeholders and then make the best decision possible on what to work on next. The Product Owner is the decision maker and collaborates and engages with the stakeholders and Developers to determine the product strategy and business model, provide strategic direction, create product vision, goals, and roadmap, research the market and users to discover opportunities, needs and pain points, analyze the market and competition, determines value propositions, manage, order, prioritize, and refine the Product Backlog, and clarify the work for the developers.
The Scrum Master is accountable for the effectiveness of the Scrum team and the organization. The Scrum Master is the team’s leader providing servant leadership to help the Product Owner, Developers, and the organization make forward progress toward their goals. The Scrum Master educates the team on Scrum, helps establish empiricism, plans and advises on Scrum implementations, leads, trains, and coaches the organization on Scrum adoption, helps removes impediments, empowers the team, enables cooperation and collaboration, increases visibility and transparency, and facilitates as requested keeping events effective, productive, and within the timebox.
The Scrum Master coaches the Team in self-management and cross-functionality. Once a team is empowered to make how decisions (Developers) and is empowered to make what decisions (Product Owner), the Scrum team of about 10 people, can become a self-managing Scrum team that collaborates directly with stakeholders and users to deliver quality valuable Product Increments that meets their needs.
And that’s what a Scrum team is all about. A small self-managing team that can just run with things and regularly delivers a valuable, quality, working product while actively collaborating with the customer. This is very different from the hierarchical approach of most organizations where decisions get made at the top and then trickle down and down from one person to the next to the next until it gets to the team building the product and those team members usually end up having zero interactions with the users of the product.
It’s the Scrum Master that is championing and bringing about this change in how organizations approach work and how organizations and teams are structured, in order to foster high-performing, highly effective self-managing teams that continuously deliver value.
And that’s the Scrum team. A cross-functional, self-managing team that regularly collaborates with the stakeholders and users to build valuable quality products. The team has 3 accountabilities, Product Owner for value, Developers for quality, and Scrum Master for effectiveness.
Next check out the entire Scrum in a Nutshell series:
Scrum is a framework for developing, delivering, and sustaining complex products. It all starts out with our stakeholders, customers, and users that have an idea about a product they need and want developed. They collaborate directly with Developers to turn this idea into reality. Developers in Scrum are not just programmers. They are part of […]
In Scrum, there are 3 accountabilities, 3 artifacts, and 5 events. The 3 accountabilities in Scrum are: The 3 artifacts in Scrum are: The 5 events in Scrum are: And that’s the Scrum Framework as defined by
The Scrum team consists of 3 accountabilities, Developers, Product Owner, and Scrum Master. Developers are accountable for building and delivering a quality working Product Increment at the end of each Sprint. They are a small group, typically 3 to 9 members that are cross-functional and self-organizing. Developers are cross-functional to remove bottlenecks and dependencies. Developers […]
The Product Backlog is an ordered list of hypotheses, requirements, features, enhancements, or Product Backlog Items that help the team accomplish the Product Goal. The Product Backlog is the team’s single source of work. Meaning, anything the Developers are working on should be coming from the Product Backlog. There are no side requests. Any work […]
In Scrum, the Sprint starts with Sprint Planning where the Scrum team plans out their work for the Sprint and creates a Sprint Backlog. The Sprint Backlog is the team’s plan to accomplish the work. Sprint planning is timeboxed to 2 hours per week of Sprint, so for a 2-week Sprint it is one event […]
The Daily Scrum is a brief daily planning event by the Developers to inspect their work and the progress they are making toward the Sprint Goal that will result in a Product Increment. The Developers created their Sprint plan or Sprint Backlog in Sprint Planning at the beginning of the Sprint. However, this plan is […]
The Sprint Review is a working session for the stakeholders, users, and customers to collaborate with the Scrum team which includes the Developers, Product Owner, and Scrum Master, and inspect the progress made toward the Product Goal based on the latest Product Increment. The Sprint Review is about getting feedback from the stakeholders and users […]
The Sprint Retrospective is a reflection event that occurs at the end of each Sprint. It is for the entire Scrum team which includes the Product Owner, Developers, and ScrumMaster to inspect how they are operating and then come up with a continuous improvement plan to adapt and become more effective as a team and […]
The Product Increment is the output of every Sprint and is an increment that brings the team one step closer to the overall Product Goal. This means that each Sprint is focused on a cohesive set of Product Backlog Items that meet a Sprint Goal and not random unrelated items. Once a Sprint starts and […]
For teams to succeed with Scrum, team members must become proficient in living the 5 Scrum values of commitment, focus, openness, respect, and courage. Commitment: In Scrum, the team commits to each other, not to other people, but to each other, on supporting each other to deliver on the Sprint Goal and Product Goal. Focus: […]
Scrum is a framework for solving complex adaptive problems with high levels of unknowns, uncertainties, or risks around what to build or how to build it. Scrum involves a cross-functional and self-managing Scrum team that uses empiricism to build products iteratively and incrementally to reduce risk and deliver early and often. The Scrum team uses […]
Back in February 2001, at the lodge in Snowbird Utah, 17 thought leaders from the software industry got together to discuss the state of software development and compare various lightweight frameworks that popped up in the late 90s because of dissatisfaction with the traditional waterfall approach to building products. The participants shared and learned about […]