STEP 9

Product Owner / Team

Use the “7 Things” approach as outlined at the top of this section. Feel free to use any of the mini-lectures outlined here if they’re helpful.

In charge of “WHAT” is to be built

While the Team is responsible for determining HOW to build a given feature, the Product Owner is in charge of defining WHAT is to be built. Scrum is careful to make a distinction here. Unlike traditional product management, Scrum enforces this separation of concerns to make sure the PO can focus on the WHAT should be built, while staying free of the implementation details. This allows the PO to focus on what’s important: the ROI of features, and ensures the team has the authority to figure out HOW to build the WHAT the PO has defined.

Responsible for ROI

The Product Owner is the person responsible for the Return on Investment of the product. She maintains the product vision to set a clear goal for the team and organization, and she determines what must be built by using that vision and by gathering requirements from stakeholders.

By prioritizing the features in the Product Backlog, she makes sure the team is building the highest business value items first so that she can get those features out in front of clients as soon as possible. By doing this, she maximizes ROI by garnering feedback early and often so she can adjust course if need be.

Gathers data from Stakeholders

Being a Product Owner is a full time job. A good PO not only spends time defining and prioritizing the Product Backlog, she also meets with stakeholders, including internal and external customers, to determine their needs.

The Single person who prioritizes the product backlog

While anyone is welcome to add items to the product backlog, there’s only one person who has the power to decide what gets built, and in what order. That’s the Product Owner. He takes all the information he’s gathered from stakeholders, including the Team who may have technical or infrastructure issues they’d like to spend time working on during a sprint to help increase their productivity or the stability of the product, and prioritizes that in a single, forced ranked list we call the Product Backlog.

Will the Product Owner have to listen to the CEO when he’s told there’s a very important client that has requested a certain feature? Sure. But the PO is the sole person responsible for taking all this input and determining the proper order for the backlog. The goal is to have a single source of definitive information for the team to approach when they have a question, and we want that single person to have the authority to make tough decisions when needed.

Accepts Working Software

Just as we need a single person to prioritize the product backlog, we also need a single person to accept working software. In fact, we give that responsibility to the same person: the product owner. He’s in charge of WHAT is to be built, so it makes sense that he’d be the only person to say if the WHAT that was built is done.

The PO can accept work at any time during the sprint. In fact, getting `sign off` on an item during the sprint instead of waiting until sprint review can be amazingly helpful in getting the team to build momentum, and can help the team avoid having stories rejected in Sprint Review for items they could have fixed if they had only known earlier. In cases where the PO accepts work prior to the Sprint Review, the team, product owner, and any stakeholders needed still have a Sprint Review at the end of the Sprint. However, that meeting changes from a demo and acceptance meeting to solely a demo meeting, which can help speed things along if you have lots of stakeholders in the room.

You can, of course, just wait for acceptance during Sprint Review, but communicating early and often with your PO is always a good idea.

Drives the product vision

Without a clear vision, it’s very hard for a team to attain “flow”. We need a clear target so that we can iteratively adjust our course to eventually attain our goal. The Product Owner is responsible for setting this vision and communicating it to the team and organization. When agile projects fail, it’s often due to the lack of such a vision.

Responsible for the “HOW”

With the Product Owner focused on WHAT the team is going to build, the Team is responsible for determining HOW that stuff gets built. We decouple these two things, in part, so that the team is free to figure out how best to do their work. For example, perhaps there are two ways to build a specific feature. One will take 50 hours, and the other will only take 5. Both approaches will meet the PO’s acceptance criteria, and the team’s definition of done.

Free from implementation constraints, the team can pick the option that’ll take a 10th of the time. It’s likely that only the development team would have the insight needed to make this determination. Keeping the PO out of implementation helps the team ‘think outside the box’ and come up with innovative solutions. After all, they’re the ones closest to the work, and therefor the people best able to figure out how to do it.

Self-Organizing/Self-Directing

Agile software development puts a lot of trust in teams. In fact, you can’t have an agile team without letting it self-organize. One of the principles behind the Agile Manifesto is ‘Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done’. We believe that teams, with clear goals, can self-organize to get their work done. They don’t need a manager or PM hovering over them, since micromanagement kills innovation and morale.

Leaderful, not leaderless

Often folks who have never done Scrum before will bring up the concern that if we have self-organizing teams, no one is taking the lead. That’s actually quite far from the truth. A good Scrum team is leaderful, not leaderless. The QA expert on the team will help his teammates learn to test a given feature, or the UI expert will help lead his team to build better interfaces. In this way leadership is emergent, not assigned by an org chart.

Team Size

Scrum says you should have teams of 5 to 9 people. Why is this? Well, if a team is smaller than 5, it’s often hard to have all the expertise you need to get a project done. Or, with a small team, it’s sometimes not worth the overhead of Scrum’s meetings and such. With a team larger than 9 people, you end up with too many cooks in the kitchen. There are far too many channels of communication for the team to successfully self-organize and communicate.

Accountability and Authority in the Same Place

By having the team take responsibility for the ‘how’, and making sure the team has everything they need to build features, we ensure both accountability and authority reside in the dame place — the team. Unlike traditional project management, the team has the responsibility and authority for making commitments as to when they’ll deliver features. They are the people who are allowed to estimate work, since they’re the ones who will be doing that work.

Since the team has the authority to make whatever decisions they need to during a sprint to get their work — since they’re not gated by any other processes or people in the organization — they’re more able to meet their commitments.

Cross Functional

Before I started doing Scrum, most of the teams I worked on were not cross functional at all. We had a server side guy, a front end guy, and a tester. We had little silos where specialized knowledge got stuck. Because of this, we’d often have a bottleneck in the development process, bottlenecks that could kill deadlines and morale.

In Scrum, we work hard to break down these silos and spreading knowledge across a team. Sure, we still have a tester who’s the expert on testing, but she makes sure to share knowledge with the rest of the team, and works to train them on how she does a lot of what she does so everyone on the team can test more. We want to end up with teams in which people can jump in and help out with whatever is needed to deliver committed items, even if the thing they’re jumping in to do isn’t their speciality or personal preference. One for all and all for one.