The Questions

The original post in the group asked some hard questions about the role of the Product Owner.  Questions about this role are normal since the original Scrum definition does not go into detail about the day-to-day work of the Product Owner.  I think this is intentional as one definition of this role would not fit very many teams and enterprises.  Let me paraphrase and condense the questions:

How does the Product Owner build and maintain the Product Backlog?  How does he ensure the Sprint Backlog is ready for planning?  And, how much time should be spend doing these things?

Study the Role

To understand the power, nature and key importance of the Product Owner role, we should first understand the big picture.  Some of the best documentation about the Product Owner role comes Roman Pichler. Look around his site for some great information.  In particular, Roman produced a slide set that has helped me many times when explaining the Product Owner role to executives and teams.  Read through this set on being an effective Product Owner [PDF] for some great insight.

The process of gathering information about story content; requirements, UI, etc. can vary significantly from company to company and team to team.   Scrum does not provide direct instruction about how the Product Backlog should be assembled and maintained. Scrum mostly says that the Product Owner is in charge of the backlog.  Lets focus on the main goal for the Product Owner with regard to Sprint Planning:

• The Product Owner needs to have at well defined stories ready at the start of the meeting.
• These need to be in business value priority order.
• There needs to be enough ready to fill at least one Sprint Backlog and maybe a few more, just in case.
• These prepared stories define “What?” is to be created and how everyone will know the creation is complete.

To meet these goals, the Product Owner can use whatever method is needed to collect, document, understand and define the answer to “What?” should be created.  Some things the Product Owner might do:

Product Backlog Grooming

In Roman’s writings he emphasizes the idea of a backlog grooming section. There are others also emphasize this idea and I agree with them. Sometime during the Sprint, the Product Owner and all the team developers will spend time fleshing out the stories for the next sprint and maybe a couple more. This allows the team a forward look to help guide the current work and keeps them on the road. Most importantly, it helps the Product Owner understand the costs, risks and benefit of imminent stories.

Stakeholder Communication

The Product Owner will call meetings with the various stakeholders (Marketing, Production, Finance, etc.) to create and refine stories. The Product Owner represents these interests and people to the developers on the Scrum Team. There needs to be communication with these stakeholders often so that their interests are well represented in the stories and hence the end product. These people are not on the Scrum Team (i.e. they are “chickens”), but they are customers, so their input is vastly important.

Team Communication

Besides a formal grooming session, the Product Owner should be available at any time to talk, discuss and meet with the team or individual developers. The best communication method is face-to-face conversation. When such is done between people that regularly spend time together, misunderstanding is much less likely to happen. Specs, diagrams, drawings, etc. are great. Do them asneeded in order to create a great end product. Documents are not the primary means of communication. Face-to-face is the primary means.

Time to Prepare and Define

The amount of detail and work in all this grooming and communication should be biased toward the present and face-to-face communication.

The detail in the Backlog request as far as features, business rules, and the like, should be only as much as needed for customers, Product Owner and team to understand each other. Once they are used to talking and working together, not very much will be needed. Stories in the next sprint or two will have more of this communicated while those further down the Product Backlog will have less. No reason to spend lots of time defining things that are weeks or months away since they will change.

The Product Backlog does not contain detail design.  They should have as little design information as possible, for the moment’s need. Maximize the work not done.  Remember, the team defines the “How?” of the work, which is the design.

• If the story is in the current sprint, there will be lots of this detail as it is implemented.
• If the story is expected in the next sprint, only as much as needed to be ready for Sprint Planning. Not too much.
• If the story is expected two or more sprints out, only as much as needed to have an understood vocabulary around the story. Not very much at all.

When a Product touches several domains (Marketing, Production, Finance, etc) besides the “product” domain, resist the temptation to do Product Owner by committee.  The Product Owner needs to be the one person that the rest of the Scrum Team asks for decisions of priority and completeness of work. The Product Owner may represent many other functional customers but those customers are not members of the team. This is not to say that developers are not allowed to talk to customers, they should. But questions of story definition and priority are for the Product Owner to determine.

The definition of done is defined by the Product Owner, based on customer input. It is part of the answer to the “What?” question. It should be in the story before the Sprint Planning meeting starts.  During the Sprint Planning meeting the developers may reveal that the story is to big or to difficult or somehow not possible to accomplish as defined. This is only because the “How?” that is answered by the developers cannot meet the definition of done for some reason. Hopefully this does not happen too often and usually should be resolved in the Product Backlog Grooming and communication with the customers.

Definition of done should also include technical requirements such as “Shall pass unit tests” and “Shall be built on the official build computer before demonstration.”  These the developers should define and follow.  The Product Owner should understand the importance of high craftsmanship to the end product.

The Product Owner role should not be taken for granted.  It is a key role that each team and company must refine in their own way.  Keep learning about it all the time.  It is one focus that almost always can be improved.

The best way to make sure a poster has value for your company or team is to start out with good information.  Platitudes don’t cut it.  Real value from the information is the best measure of good content.  Let me tell you about the most powerful poster we have in our office.

Some time ago I encountered the presentation “I don’t like Mondays” presented at Agile 2007 by Jean Tabaka.  Her presentation is an excellent summary of great things that energize meetings of all kinds, and Agile meetings in particular.  (After you read this post, go watch the video.  It is well worth your time!)

In the presentation, Jean provided the content for our poster as a “Focus On / Focus Off” list about communication.  A picture of the poster is to the right, hanging in our main meeting room.  The simplicity of the content belies it’s power:

Focus On / Focus Off

Inquiry rather than Advocacy

Dialogue rather than Debate

Conversation rather than Argument

Understanding rather than Defending

Why

We found that hard decisions in our meetings led to some conflict.  Conflict is to be expected, even desired, in creative work.  Passionate and creative people will have conflicts if they are effectively engaged.  The trick is working through the conflicts such that the customer and the team are happy with the results and each other.  An Agile team needs to learn tools of compromise, knowledge transfer and empathy to get through the conflicts that will come.

One particularly contentious Sprint Planning meeting bothered me as we proceeded into the Sprint.    We had simply postponed some of the difficult decisions because the logjam of opinion was impenetrable.  (Everyone was civil but feelings were strong.)  As we approached the end of the Sprint, I worried about the Retrospective and the planning to take place after that.  How could we quell the conflict enough to make decisions without damaging the team?

One evening, during the last few days of the Sprint, I found the video of Jean’s presentation.  I had to try this “Focus On / Focus Off” discussion!  I wrote the title and described how our internal focus changes the context of our communication.  I then wrote each “rather than” pair one at a time and asked a team member what that pair meant to him.  I then asked another team member how one would act or speak if focused on the left word and then on the right word.  I did this with each pair of words, discussion their meaning and effects.  I then asked that we each do our best to focus on the words to the left as we work through the retrospective and planning.  I then taped the easel page to the wall as a reminder.

The feel in the room softened, opened as we had this discussion.  Yes, that sounds all “warm and fuzzy” but it is true! The Retrospective was excellent and the Sprint Planning meeting that shortly followed was very fruitful.

Power

Can a poster have such power?  If you have a Scrum Team willing to work for the better of the project, for the customer, it can.  We each need occasional reminders about what open communication really means.  A reminder that our thoughts are valid and need not block all other ideas to retain validity.

Today, more than a year later, the hand written poster hangs on the wall right where it was first taped up.  It still helps us to disagree, learn and grow.  And work with each other the next day!

@estherderby If there was only 1 agile practice what would it be for you? For me, it would be retrospectives as they are foundational.

I fully agree that retrospectives are the one powerful Agile practice to do if no others are yet implemented.  I posted:

@estherderby The first retrospective we had was stilted and shallow. And it improved the culture of the team dramatically!

As I posted that brief message, I knew a blog post was needed to fully explain the strong statement.

Getting To Retrospective

The team had been doing “Scrum” for some weeks.  I put Scrum in quotes because we really were not doing enough of the practices to use the term.  Key members of this team and engineering management were not fully committed to Agile and Scrum.  We were adopting practices slowly, as the acceptance of these key players allowed.  We were doing:

• Weekly Sprints
• Weekly planning meetings
• Daily team status meetings, like a daily Scrum
• Using a team board with tasks

I had been requesting that we start doing retrospectives, even just do one to try it out.  The biggest objection was the perception that it would be a waste of time on a “feel good” measure of little value.  Percistent discussion and pointing out the well known desire to gather “lessons learned” finally prevailed.  We scheduled one retrospective as a test.  Maybe they just wanted to stop me asking.  Whatever works, right?

The Culture

Prior to beginning our migration to Scrum, this team had a very traditional structure.  A brilliant engineer was the Team Lead.  He determined tasks for each of the team members.  As we started doing sprints and team level planning, this lead continued the practice of defining tasks for each team member.  We shifted to emphasizing that each team member needed to accept the suggested tasks.  The reality remained that the Team Lead was determining the work of the team.  (This practice was not Scrum, nor Agile.  A dicussion of the value of such a slow shift to Scrum is another blog post.  Or an essay!)

Several members of the development team were quiet.  When discussing development one-on-one, they had great ideas and interesting things to say.  When in the team meetings, they were largely silent and simply agreed with the more dominate personalities in the group.

The Setup

I chose our Training Room as the venue for the retrospective.  This is also the same room where sprint planning meetings were held.  Usually the room has four tables pushed together in the middle of the room to form one large table with 12-14 chairs around it.  For most meetings this arrangement is appropriate but for others, it is not conducive to the meeting goals.  (See http://blog.dayleyagile.com/2009/02/23/the-real-elephant-in-the-room/)

I split the tables appart, pushing them out to the edges of the room with the chairs lining three sides of the open space in the middle.  The team board showing the task cards for the sprint just ended was positioned at the front on the wide marker boards, now erased and ready for writing.  Sticky notes and pens were liberally sprinkled around the room for attendee use during the meeting.

The Meeting

During the meeting several notable things occurred.

• As attendees arrived they made comments about the organization of the room.  Some were quizical, some were intregued.  Two who brought notebook computers were unhappy at the lack of a table for thier electronic distractions.
• I asked each attendee to state what value they though they could get out to the meeting.  Their responses were interesting.  More important was getting each of them to talk so each would be more likely to speak up during the meeting.
• Each was asked to write sticky notes of what went well and what could be improved.  This minimized the effect of dominating personalities and ensured that everone had the opportunity to contribute.
• Dot voting with performed to find the top improvements to work on.  The Team Lead was particularly irritated that his three dots were not enough to force his desired improvements to the top of the list.

Immediate Changes

As I think about it today, this retrospective was not particularly effective for the practical work of the project.  We did not even execute well on the choosen top improvements.  The team member interaction started changing from that day forward.

• Everyone contributed at a team meeting, maybe for the first time.  And it was not just the individual answer at the beginning, though I’m sure that opened the door.  Every person provided sticky notes and comments throughout the meeting.
• Several times comments along the lines of “I didn’t know you thought that” were heard.  The following planning meeting that afternoon was more lively than ever.
• Right there, in the meeting, the Team Lead role began to be absorbed into the team.  This was difficult for the dominate personalities to take but the “human side” of the team started forming in a positive way.

Retrospective Power

As time went by, this team began to gel further.  Participation in the meetings and with each other increased.  The team unified further, more easily able to request changes from the larger organization.  We also had serveral meetings that dove to the heart of individual difficulties, something not possible without higher levels of trust.

Several of the dominate personalities eventually left the company, perhaps in part as a side effect of at more egalitarian team environment.  We continued to have retrospectives and attempted to apply the actions to improve our work and team.  This team eventually produced the product and has now moved on, mostly joining into a team designing our next generation project.  Retrospectives are a key part of the work and we never skip them, ever.

If you are doing a slow adoption of Agile practices and must pick only one practice, do retrospectives.  Do them regularly and with serious attention.  Daily meetings, sprints and team planning are powerful and look easier to start doing.  Real change on with the team’s human dynamics really happen when the retrospective becomes part of your habitual practice.