Who Is on the Scrum Team?

A Scrum Team is:

The Product Owner is ultimately responsible for what the Scrum Team builds. This entails prioritizing the Product Backlog, making the final call on requirements questions (while not necessarily providing detailed requirements), negotiating with the Scrum Development Team during the Sprint Planning Meeting, and declaring whether demonstrated items meet their acceptance criteria at the Sprint Review Meeting.

Scrum avoids the term “Product Manager” because an effective Product Owner does not manage the team in a conventional boss/worker sense.

The appropriate level of involvement of the Product Owner will vary.

The absolute minimum would be attendance at the Sprint Planning Meetings, the Sprint Review Meetings, and backlog refinement meetings. If your designated Product Owner cannot do that much, you may as well admit you don’t have a Product Owner and perhaps someone else should step up to the role.

At the other extreme our Product Owner might be an “available customer” in the team room full time with the Scrum Development Team.

Should the Product Owner attend the Daily Scrum and the Sprint Retrospective? You’ll have to discover the right answer for your team through inspect and adapt. If there’s any whiff of the boss/worker dynamic, I’d suggest letting the Scrum Development Team decide whether to invite the Product Owner.

In high-stakes projects, we suggest the Product Owner be supported by a “product team” of analysts and other stakeholders.

When Scrum is scaled to multiple teams, the Product Owner role gets even harder. We’ve seen this handled with a variety of delegation approaches, each having pros and cons.

The Scrum Development Team is a cross-functional group of about seven people responsible for producing a potentially shippable product increment every Sprint. We give them as much autonomy as the organization can stand, while holding them responsible for the outcome at the Sprint Review Meeting.

People are sometimes surprised to learn Scrum Teams are expected to produce tested product increments rather than rely on a QA department for this.

While Scrum doesn’t specify exact team configuration, we recommend each team contain a combination of skills including analysis, architecture, coding, and QA. If your product requires specialized knowledge, you may need domain experts (“Subject Matter Experts”) right on the team. Your particular team may also need an information architect, a UI designer, a DBA, or a sysadmin. Teams building products such as video games will have their own variety of required specialists.

Highly-skilled teams may adopt techniques from the “Extreme Programming” world such as Test-Driven Development, merciless refactoring, pair programming, and continuous integration. Mixing analysis, design, implementation, integration, and test into the hourly workflow blurs the lines between the traditional roles we’re accustomed to on waterfall projects.

The cost of context switching is higher than most people realize. Our best shot at team ingenuity is a team of dedicated members who aren’t distracted by other responsibilities. But what if we only have one specialist (a DBA or UI designer, perhaps) for two teams? Have that specialist attend the Sprint Planning Meetings for both teams, committing only to how much work can actually get done. Then inspect/adapt whether this will work in the future, or raise the visibility of needing more specialists. Fortunately, team swarming (especially when we collaborate in a team room) provides a great environment for cross training.

In extreme cases, several teams may depend on a single specialist. This person should probably be considered a consultant to the teams, rather than a full team member.

The Scrum Master keeps the process moving, guides the team towards self organization, helps resolve impediments for the team, keeps the Scrum artifacts visible, and does what ever else it takes to maximize team productivity and ingenuity.

The “master” part of the word misleads some — the Scrum Master does all this with no authority. Unlike a traditional PM, the Scrum Master isn’t a taskmaster. The Scrum Master does not make commitments on behalf of his team.

So what does the Scrum Master do? The answer depends on skills and situations. I’ve created an example list of things to think about.

Coaching a team towards self organization isn’t an easy skill to learn. To get help with this from people who’ve done it before, consider spending a couple days at one of our courses.

mj

To learn more about Scrum roles, see the 6-page illustrated Scrum Reference Card and this entertaining introduction to Scrum video.

Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Posted in Agile

Leave a Reply

Your email address will not be published. Required fields are marked *

*