Keep the questions coming… you never know when a thread may wind up on this site (or in a cartoon)!

Today we introduce the role of Product Owner. Not necessarily a Pig, and not quite a Chicken. And, as we have covered in the past, definitely not a PigKin!

Why is this role soooooooooooooo important, you may be asking yourself?

Ask.

Go ahead.

Or at least play along. Thank you.

When I explain the overall flow of Scrum to new teams — or new team members — I am sure to emphasize the difference between a Product Backlog and a Sprint Backlog. What are the differences between the two? And um, Mike, what does this have to do with the Product Owner role?

Hang with me….

A Product Backlog (in Scrum… remember… this is all about Scrum) is a list of prioritized stuff that the Product Owner wants “done” for the entire project. It is owned by the Product Owner. Now, the Product Owner is the person responsible for negotiating the priorities and items on that list with both the Scrum Team and all the outside stake-holders on the project (the many many Chickens).

I affectionately call this “The Noise” to the team. Why is that? Because the working list for the Scrum Team during each iteration is not the Product Backlog, it is the Sprint Backlog. Let me explain the Sprint Backlog to you, and then we can delve into the reasons why the team desperately needs this distinction of work items.

A Sprint Backlog is a list of prioritized stuff that is taken off the Product Backlog for completion during a Sprint, or iteration. It is compiled and agreed to by the Scrum Team (Pigs) and the Product Owner. Chickens have no say as to what the Scrum Team can commit to completing in a Sprint. Thus, the distinction. Say it with me now — a Sprint Backlog is owned by the Scrum Team doing the work within an iteration. The Product Backlog is owned by the Product Owner and can be — should be — constantly negotiated outside the team room with other Chickens. Thus the reason for the Product Owner shielding the team from “The Noise.”

Why should the Pigs and Chickens actually care what the difference really is?

The Product Owner role can suck.

There. I said it. Why?

Well, this role – in conjunction with the ScrumMaster — is responsible for making sure that the various Chickens and Pigs understand the differences between the two types of backlogs. Here is where the role — or more specifically the person playing that role — can break down…

During a Sprint, while the team is working off the Sprint Backlog to burn down stories and tasks, the Product Owner must be available to the team for answering questions about such-and-such feature. Must be. This is non-negotiable. Now… during the Sprint, the Product Owner must also work outside the team room to continually negotiate and re-negotiate the list of items and their said priorities on the Product Backlog. Again, the Product Owner can shield the team from, “The Noise.”

Read that last paragraph again. I’ll wait here. Whooo deee dooo. [Kidding -- I really am a patient person!]

Where can people implementing Scrum screw up this concept? Oh, my dear reader, in a myriad of ways.

Sometimes during a Sprint Planning Session, a team will try to sneak in something called “Kickers”.

What this really should mean is the ScrumMaster should be kicked in [the place the sun does not normally shine] if “kickers” are allowed into a Sprint [contact me if you need help!].

“But Mike [insert whine here]…. We are difffffferent.” Ugh. There is that statement again. May I remind you — every team is different…. that kind of makes you the same (wow… how so very Zen, eh?).

What is the correct answer when you see this happening, and how can you tell this is even happening during a Sprint (because sometimes teams get “sneaky” and lo and behold, their burn down chart is not heading toward zero, and people are working and doing “stuff” [kind of like a gerbil running on that round thing in their cage]).

The first clue is the burn down for the team. Trust me, the team needs to understand it is a guide for them to use — not for some compliance wonk to check off a box during an audit (an unfortunate symptom) or a Chicken Manager walking into a team room and having a coronary over the fact that the team is not working at the “ideal time” displayed on the burn down sometimes).

I usually work with teams during a Sprint Review and Retrospective and ask them… “Hmmm… You did not burn down to zero again…. why is that so?” The stock answer — after the whine described above — is something along the lines of, “Oh Mike, it’s OK, we never reach zero.”

Now, instead of going right-wing-religious-Scrum-Masterish on the team (trust me, whenever I try this it does not work)…. go back to some of the basics of Scrum. Explain the difference between the Product Backlog and the Sprint Backlog. The Product Owner needs to back you on this. If the Product Owner does not back you on it, the team is probably screwed anyway and needs more than just help interpreting a burn down chart.

The team needs to focus on finishing the work they committed to on the Sprint Backlog. If people are sitting around bored or surfing the net (and the Product Owner, who is actually writing the check for the team is not OK with that) during a Sprint, and if say a developer could not possibly help a tester [ding ding ding red light alert here too!] then said developer should say something at the next standup, own up to the fact that they need work, and negotiate taking something out of the Product Backlog and bringing it into the Sprint Backlog to be worked on.

So how is this “different” than a “kicker” story (or, as I usually see, cherry-picked stuff that is low priority for the business but fun to work on)?

It causes people to start thinking like a team. Hmmm… Insert some cool music you like right here….

Maybe a developer pairing with a tester is not such a bad idea. Maybe saying, “I need something to do,” takes some major-brass-lined-cajones. Maybe people can start working as a team instead of thinking in their old silos.

“But Mike… [insert whine here].”

If you get to this point [I have]… shut-up, walk out the door, and let the team do whatever they think is right.

Whatever that is really is not Scrum.

And that may be OK.

So….

If the team is happy with it, go ahead and let them hack away at it. Work with teams that sincerely want to learn how to improve. They exist. Trust me.

When [or IF] the team gets sincerely interested in working as a team again (sometimes they do not, and no “methodology” can help here) be there to help them.

Shoot. I hope that was not a major tangent.

But I hope it shows you how delicate a role the Product Owner must play.

Welcome to the team!

Please send comments, questions, criticisms, ideas, or whatever here. You can also enter The Scrum Community to discuss this cartoon and other Scrum topics. Thank you!