Really feeling the team. When I wrote the book I was thinking the subtitle was for me inside out. I looked at the product owner’s role and it’s an external role in that it’s trying to understand the business dynamics, it’s trying to understand the customer and then feed those requirements to the team. I really think the inside part of a lot of teams needs the most attention where you are feeding pristine, well-defined requirements to the team. I think that’s the primary part of the role.
Using Scrum terminology it’s feeding the team a well-framed, well-behaved backlog of stories that are thoughtful, that are well-formed, that are not too feature-oriented, that traditionally Scrum does. You don’t have a thousand stories, you have 50 well-cooked stories or 30 well-cooked stories that you are getting ready to stage within the team, that you’ve vetted with the team. I think that the primary responsibility is that. I talked about four roles that they have in the intro to the book. I said they have a leadership role, a business analysis role, a project management role and a product management role.
I think they need to take all that and focus a lot on that, a lot of those things are focused towards the team. Even the leadership part of the role I think is important from an envisioning perspective of providing product vision and energy. Does that make sense?
2. It does make sense. You talked about a well-formed backlog. What do you mean by that?
I use the term grooming a lot in that I think it’s an organic thing. I’ve done some sessions here at the conference and I really want product owners to consider it not a static list. It’s not a one-time visited list, like a use case and then you never go back to it and you pop it into your team and you expect excellence of execution. I have a lot of guidelines around revisiting stories. They’re epics and they’re refined stories and they are broken down with the team. You might have technically challenging stories so you may want to vet with the team.
You may want to have research spikes where you want do to do a little bit research in advance of execution, executing them in a sprint or an iteration. Then you want to break right before sprint execution. The team should have no surprises in sprint planning. It should be this sort of evolutionary path of well-formed stories being created and facilitated by the product owner with the team. That may sound "Waterfally," I don’t mean it to sound that way.
It’s Agile principles we’re using just in time and just enough, but I think there is a dynamic grooming aspect that needs to be done. That’s part of it, that’s a strong part of that role of a well-formed backlog.
That’s not actually due to my four roles. The product ownership role is a Scrum artifact, we created the role. Schwaber and fellows created that role to be that customer liaison and that customer facing role. In a lot of organizations, in my experience the product owner is evolved from product managers. If you look at the classic product managers, one of the things they do when I was writing the book, it was interesting there is this group called Pragmatic Marketing.
They do training, etc., and they are very strong in the product management space. They had this wonderful chart that talks about the role of a product manager - it’s a nice hierarchical chart. I think there are 37-38 responsibilities on the chart. One of the first things I did when I was writing the book was I mapped the product owner role, at least my view of it. I mapped it to the chart - depending on the definition, only 8-11 of the Scrum role responsibilities mapped to the chart.
What that says is in a lot of organizations the product owner role (from an Agile perspective we have high expectations) is a part time role for many product owners. What are the other things they are doing? They are doing things like pricing. They are interfacing with real customers, they are going on road shows, they are doing demos, they are putting it in the marketing plans. They are doing roadmaps, they are forecasting out. We may not want to forecast out. I talk about a good backlog you don’t want to go too far ahead.
The business expects them to forecast 12-18 months out, at least from a business case perspective. They are putting together a business case, they are signing deals, they are putting together marketing literature, they are designing launch plans. There is a stressful role, this is one of the things I’ve discovered. I think you see that in a lot of Agile product owners, that they are sort of stressed out. They are torn making choices. One of the things that I find funny is there is a lot of debate in the community for the last few years - "Can there be only one per team or are there many?"
One of the reasons I like the "many" option is because of the nuance of the role. It’s like how can one person do all of that and do it effectively. You need that external activity to feed into that backlog, you need the customer analysis, you need the business case analysis, you need the market differentiation. That full time aspect needs to be fed into it. I actually like that option of having multiple product owners or a singular decisive product owner, but that has a supporting cast around them. I think that can be very effective.
4. Would you consider the product owner to be a part of the team?
That’s another one of those debates. And I don’t know what you think. We could probably debate this. I think there is a lot of debate in the community around Scrum Master. Are they in or out? Product owner: are they in or out? I think they are specialized roles, they are clearly specialized roles. I like the model, in my coaching, where the Scrum Master is a member of the team and they have the mental model that they are in the team and they present that to the team. I like the product owner having the mental model that they are part of the team, their first level of loyalty is into the business.
That doesn’t mean they get fired or anything or they ignore the business or the CEO when they are knocking on their door they can do that for the team’s sake, but they really are fundamentally loyal to the team and they are a member of the team. I want them to behave that way. One example of that is I like you’re the recommended product owner looks at the strengths and weaknesses of their team and normalizes the backlog towards those strengths and weaknesses and doesn’t just care. If you’re business focused, what do you do? If your business drives you towards a set of stories, you shove it down their throat and you make it happen.
You don’t consider their strengths and weaknesses; that’s sort of irrelevant. It’s business priority. But if you are looking at complementary skills, I have a silly story of your strongest database engineer on your team goes on maternity leave. Your backlog is heavy with database stories. Would you adjust those stories to wait for them to come back, potentially, and to then leverage the strength of the team in that way? And would you change priority a bit to normalize towards or renew it - look at different strengths? Oh, perhaps, let’s leverage our UI strength.
I think that’s fair game and I think that comes from being part of the team rather than being blindly driven from the business perspective and then just ask the team to suck it up.
5. Have you ever worked with a really great product owner?
I’ve worked with several great product owners and that’s why I really honor the role. I think it’s an incredibly though role. And other partners, other colleagues that I’ve run into at conferences we joke that "If you find a good one, buy them whatever they want, feed them well, give them time off, throw them T-shirts or whatever you can because it’s an incredibly tough role." If you have a good one, honor and take care of the good ones. I have and I think they run this balance of they focus inward and they have this balancing act of focus inside out.
So focus first inside towards the team, feed the team well, with the business perspective and then circle round and make sure the things are tidy on the outside. Then they iterate and do that. I think they do it well. When I think of the best ones, the thing that stands out for them is they engage the team in understanding the future. I call that "future casting". They don’t just feed the team the backlog, but they feed the team and they share with the team the competitive landscape. They talk about competition periodically, they talk about where the market is going and they share this with the team.
They share their vision and their fears with their team. What they are trying to do is to get the team... The backlog is just work, but then there is this higher level view of where we go, where we need to be, what is the business. They even share the business pressure that they are under and they are under it with their team. They share these drivers. And what happens is they are trying to get the team to share the view so that they are trying to engage the creative energy of their team not to execute the backlog, but to meet the overriding goals and objectives.
So, use their creativity and to create that shared vision so that the team almost becomes a shared product owner. I think the best ones connect to the team in that way. What’s the payback for them? I think they actually get accelerated. So it’s not just by rote story execution and I’m not just counting that. By-rote story execution is really hard and teams can excel that, but it gets to the point where teams might say "That set of five stories. You know what? I understand the marketplace, I did some research last night. Those are irrelevant right now. Let’s get rid of those.
In fact, you know what they’re irrelevant and I’ve replaced it with four more that are smaller than what you thought. We’re leveraging some of our architecture, we built some framework hooks to make it really easy to do that. We think we can creatively really solve customers’ problems in a very new and novel way." I think the best part is to sort of engage that spirit in the team.
I’m just going to name drop because it’s the best advice that you can provide. Mike Cohn talks story writing in workshops. If one goes in, we have no backlog, so what does one do? One way of attacking it is just the product owner going into their office or something and seeding a backlog and they can just write that. They can do that for a few days and create a seed backlog that is then exposed to the team. They create some brainstorming around that and that’s not ineffective. That’s just serving, it’s very quickly seeding the team and then driving some brainstorming.
I like story brainstroming workshops as the place to start. If I have a greenfield project, I have no stories in my belt. If I am a product owner I immediately work for my team and I’m like: "Hey, let’s get together and let’s talk about stories. Let’s start writing stories together as a team." Mike talks about this as one of the best ways to scene story-writing workshops is from a role-based perspective. One of the first things you do is "Let’s brainstorm system roles or lightweight personas." Then you drive your story brainstorming from that. Nuts and bolts it’s do that.
What would be another nut and bolt? How many of those do we need? Do we need thousands of those? I think that might be a little bit of overkill. We might want to generate (and typically these brainstorming workshops generate) a lot. One of the next things you might do is winnow it down into what future-oriented epics, midterm epics that might be in play and then a very small set of epics that you actually want the story to execute and call it 20-30-40 epics that you start breaking down. I give some heuristics and I’m trying not to be prescriptive, but I give some heuristics in the book that I talk about.
Twenty percent of your backlog is stuff that’s about to be executed. Thirty percent are epics that you may or may not care about and 50 percent it’s just fluff, they are just ideas. You really don’t want to have more than a few releases, if you will, of backlog in. So maybe 100 of those or something. I think that’s good advice because don’t want to be wasting much time on things that are a year or two out. I’ll tell a story that might embarrass, but I’ll leave the name out. One of our product owners that I contacted, I was talking to him (I’m a coach there as well) and I was asking him how many stories are in your backlog and I think he had 536 stories in his backlog.
He was incredibly proud and he said "It goes into 2012. I’ve got things laid out end to end. What a powerful story are we going to tell in late 2011!" Our marketplace is incredibly dynamic. God bless him. His heart was in the right place. Maybe he had more time than he should have had, so he should have been looking externally a little more. That’s actually probably true and he said, "Should I do more?" And I’m like, "No, you should throw some of those away. In fact, quite a bit of those away. And just don’t even worry about them." I think in the dynamics of the backlog, when you use story brainstorming workshops, keep a very short list, really keep your eye on the ball.
I like this beginning-middle-end game approach of attacking backlogs which is what’s right around the corner, what’s two, three, four sprints away, what’s a release or two away and then stopping. When I’m doing grooming, sometimes it can be very boring just grooming epics or it can be very boring just talking: "Oh, we have this really well-defined story that’s come around let’s hammer on it again and again. I like in my grooming sessions to change the focus of a backlog in a section and we’ll look at a few epics and we’ll break them down. We’ll talk about them and then we’ll change focus to what’s right around the corner, then we’ll change focus again. I find that to be pretty effective.
I think there are two general methods that I’ve seen. Schwaber set the tone from a reference perspective and I think a lot of folks have gotten lazy about it. He recommended 10 percent of a team’s time… In the original Scrum book he talks about 10 percent of the time is allocated towards grooming, towards backlog refinement. What I found is a lot of teams have just skipped over things and forgot things. I interview or I talk to teams, I do polls when I do a session. I think 80 percent of the teams have forgotten that. There is a lot of not grooming out there.
Don’t just create a backlog and then just let it be stale. That’s a terrible approach and one of the smells of that is if you are going into sprint planning and you have incredibly long sprint planning sessions and you are doing a lot of design, one of the clear smells of you have not been doing enough grooming are these painful non-crisp sprint planning sessions. Folks are getting blindsided with stories that they know nothing about, that they haven’t been vetted. Grooming is this process of iteratively vetting the backlog so that the team is thinking about it.
They are thinking about it, it’s not just writing acceptance tests, it’s also thinking about threads of execution I think of through the backlogs - for example, architectural cohesion or design readiness. "Are we ready for this? Do we have frameworks? Do we need to do a framework extension for this?" I even think of quality attributes they are going through. The team is starting to grok and to get ready for "What are the qualities, the testing implications for this, the automation implications?" They are vetting that over time.
I like to take that 10 percent. At iContact we have grooming meetings, one-hour grooming meetings twice a week. Every team gets into a room, they change the focus, they come to talk to one another and they discuss stories and they do it depending on the skills of the Scrum Master and the skills of the product owner. They are moving around the backlog, they are discussing those things and the team is getting more and more information around it. They’re defining the acceptance test. We will project that on a wall. We have a system that we use to maintain our stories and we are making changes and adjustments along the way.
If we want to break a story apart we do it right there, in grooming. If we have relatively crappy acceptance tests we will refine them, we’ll take a minute or two and actually add a few acceptance tests if it strikes the team right there. Or we’ll ask someone to do it offline. That’s the meeting. The other thing we do is occasionally for stories that are complex, for stories where you can spin your wheels on that for a little bit longer period of time, we’ll assign them for someone to vet offline. I ask a team member or for volunteers for someone to go. What they are doing is grooming that on their own with the team.
Then, the next grooming session they’ll bring the knowledge they found offline and they’ll bring it back into grooming. I call that an informal spike or research spike. The third thing we do is actually we invest a lot (which is not a grooming proper activity) in research spikes, not excessive. I hope you know what I mean by that. To me it’s a user story that instead of driving code it’s driving knowledge, it’s driving some research and design knowledge and maybe some prototyping. It’s time-boxed, it’s short and it’s there to answer the question. If we’re trying to break down the story and everyone looks clueless around the room and you simply don’t know where to go, then the research spike will drive that knowledge.
Part of our grooming is driving those spikes. Part of getting ready for execution, in our view, is sprinkling spikes effectively in advance (not too far in advance) in the backlog to gain that knowledge to then write stories. The wonderful output of the spike is giving me a set of broken stories that are well-estimated and that are well-understood for later execution.
I’m going to go back to… You can tell I’m a wordy answer guy, so I can’t go "Yes" or "No." I’m a real strong proponent of having sprint goals, meaning you don’t just stage a team with stories. You can stage a sprint with stories, teams define tasks for those stories. I like to start with a goal, so that the sprint has a success goal. You can have multiple factors. We the unwilling, led by the clueless are going to deliver some major feature and we’ll exhaustively test it or we use usability testing and we’ll deploy. So a compelling goal - I was kidding there a litte bit. A compelling sort of an energizing goal that the team can rally around.
Then what I like about that goal is, as the team starts executing and things are slipping away, I want the product owner and the Scrum Master, but primarily the product owner, to be helping the team realign the story mix to that goal. The question is "If we’re losing ground, can we recover the goal? Can we drop a story? Can we reframe scope to recover the goal?" I think not only as long as we can do that but I think it’s a responsibility of the product owner to help the team reframe towards success. I talk about making lemonade out of lemons.
I think every day you are trying to do that. Sometimes you’re going to just fail a sprint, you are not going to deliver to your goal. That’s different. You would recognize that day by day, that we’re losing traction to that. I think you can even re-plan the sprint. I don’t know if this is the correct ceremony or not, so if subject to judgment, but in the book I recommend this as well. I think the product owner needs to look the business in the eye and the team in the eye and assess sprint results and to call a sprint a success or a failure. A lot of folks may disagree and that’s fair, but a lot of folks don’t like the F-word.
I’ve had so many discussions with organizations "We can never fail the sprint. We don’t fail anything." It sounds like a strange business to me, but that’s OK, I honor that. I can add we do fail them, but it’s not an end state, it’s not a last day of the sprint sort of activity. We’re spending days and days trying to reframe scope, trying to reframe the goals, trying to get the team to creatively try to solve their problems. Then, if we do fail, we honestly look the business in the eye in a sprint review and say "We failed the sprint." We are not embarrassed about it, we fail forward. With the teams we really have this notion of failing forward.
In our retrospective we’ll truly investigate the "why" and take corrective action for that. We will also proudly demonstrate what we did deliver. I try not to have an embarrassing moment around it. One of the things I’d like our product owners to do for sprint reviews (this is a tactical thing) is I believe they should set the stage. In the beginning of a sprint review they should stand up, they should talk about the sprint goal. They should talk about how hard their team worked, what trials and tribulations they went through. This is a few minutes, this is not a half an hour speech, but for a few minutes they should be presenting, I think, a sort of a synopsis of the sprint.
So they frame it from the marketing point of view, so folks know what this team is doing. Then you’ll and you’ll talk about it. "Hey, we failed" or "We succeeded" and then "Let’s look at results and then we’ll have a wrapper." I think there is a lot of responsibility there of the product owner of staging unembarrassedly "Let’s deliver what we can, let’s make the adjustments that we can and let’s honestly look ourselves in the eye, call what it is and move on."
Let me give you a story. This is a true story. I’ll leave names out, but I think it illustrates what I’m talking about the power of the sprint goal. There was a team that I was coaching in our local North Carolina area. It was a very small startup company and they wanted to get funding and they wanted to take their product to this venture capital demo facility to gain venture funding. I remember one of the leaders, one of the co-founders said to me "It’s like we’ve never hit a date in our life, Bob. So, what are we going to do?" They weren’t Scrum, they weren’t Waterfall, they were chaotic; they were a startup.
He said "We probably need to hit this date. So why don’t we do this Scrum stuff?" Their very first sprint was when I did a little training and we kicked them off and I figure it was a three-week or three and a half week sprint or something. In the end of the sprint it was time to do this demo to this event in California. I tried to talk them out of it. I said, "I don’t know if you want to change any method, even if it’s not working for you." The first time you try something new, your company’s future is on the line, but they were insistent. So we did that. I did a little bit of training and we planned, did stories, brainstorming, generated the backlog.
It wasn’t a very long backlog; it was only one sprint. They may not have had a second sprint. They started executing. One of the curious things when I went off to the West Coast and I left the product to the newly ordained product owner and the newly ordained Scrum Master there trying to guide this team, the product owner called me on the second day on the West Coast. It was like 5 a.m. and I was wiping stuff from my eyes. And he said "Bob, the story changed. Some tasks are changing. What the heck is going on? What do I do? Imagine that! Have you ever seen that happening?" And I said "Yes, of course." What’s volatile in sprint? I think tasks are incredibly volatile.
Sprint planning is a wonderful sort of exercise of getting folk’s views together on a singular event and getting work lined up, but tasks change. Usually the same day we’re throwing tasks out, we’re adding tasks, we’re ripping them up or we’re moving them around. Do stories change in a sprint? I think the same thing happens - volatility comes in and changes the view. In this case their sprint goal was "We will have a compelling demo of our product, of features that work in our product that we can make work and that will generate funding for us."
That was the goal. Does it make sense? Not a by-rote list of tasks, not a by-rot list of stories, but we needed to desperately make money and compelling. It was incredibly important for them. They had a 10 minute on stage demo to demonstrate the most compelling business features of their product. This was an ongoing event, so these weren’t folks that were easily swayed, it had to be compelling. Every day that we made adjustments, every day of the sprint adjustments were made. What was the measure that the product owner used to make those adjustments? He compared every adjustment towards one - the goal.
He kept coming back to the goal. - "Is it compelling?" "Oh, we have bugs in that path. What are we going to do about that?" "We can’t execute that! We don’t have the time for that. I still need to find another path." Working with the team, collaborating, the team would suggest different alternative paths, things that they could implement, features that they could implement, stories that they could implement. That goal was really their guiding light. It was their lighthouse, if you will, to guide them through this way of making adjustments and changes. That’s what goals do, that’s what you measure your adjustments against.
"That’s a boring thing, but we need to do a unit test there." Again, even your quality propositions were measured against the goal. I’m not talking about writing terrible code, but it was that defining measure for that team.
10. Would you ever tweak the goal itself?
I’d like not to do that. What would I do? I think that the product owner brings it to the table for sprint planning and then what I’d like is he/she needs to socialize/rationalize with the team, take feedback and make it a shared goal. Once that happens (I don’t like doing that; I like tweaking more tasks, I like tweaking stories), to me, if we tweak the goal, given my story, what have we done? We now change the entire framing, the entire point of the sprint. I’d like not to do that, if it’s a well-crafted goal (I don’t know if that’s that hard), a thoughtful, a high enough level goal.
A terrible goal is "Implement story number 320, 328" - that is not a goal! Or "Get delivered 28 points at this sprint" - that’s not a goal! It’s something that we have a lot of flexibility under the covers. Therefore, I actually think if you change the goal you’re changing the entire intent of the sprint; you probably want to re-plan the sprint. Or cancel the sprint or whatever and stop and then restart and then reframe your goal.