All rights reserved. The information contained herein is subject to change without notice. ©2009, Cognizant Technology Solutions

§  Last Updated: January 8, 2012

Taking the Product Owner to the Next Level

Introduction §  The intended audience for this workshop is the Product

Owner and their immediate management.

Five Primary Responsibilities of the Product Owner

1.  Values Reinforcement 2.  Engagement 3.  Representation 4.  Authority 5.  Approvals - of both Story Content and Functionality

3

1. Values Reinforcement §  First, this assumes that your organization has settled on the Agile values that you want

to use for your Agile journey. They need to be understood by everyone – from the business sponsors down to the individual team members.

»  Examples: Transparency, Feedback, Courage, Respect, etc.

§  As the Product Owner, you need to understand how the values chosen affect your day-to-day work, and interaction with the team as well as those supporting the team.

»  Every activity performed by the team, every meeting held by the team, every document produced by the team should be able to be traced back to one or more of the values.

»  WARNING: If there is an activity performed or document produced that either cannot be traced back to at least one listed value or is out of alignment with the values, then that is going to become a source of conflict for the team.

»  The PO should periodically discuss these with the Scrum master for the team, taking a critical eye to every meeting, every activity, and every document produced, comparing those with the list of values.

»  Example 1: the daily scrum devolves into a status meeting. The daily scrum should at minimum be supported by the transparency and feedback values.

»  Example 2: a team member produces an issues & risks document and is told not to share that with the product owner and business sponsor. This will cause a rift in the team, and the product owner may become upset when it finally comes to light. There’s nothing inherently wrong with producing an issues & risks document – in fact, it may prove to be a good step for your team, however “hiding” it from those inside or outside your team will cause a conflict if your team has respect and transparency as values.

4

Values Exercise (sample) §  What are the Agile values for your organization?

»  Do you know them by heart? »  Have they been endorsed by everyone from the business

executive down to the individuals on the teams?

§  When is the last time that you met with the Scrum master and other “leads” to discuss values?

§  If you have not yet defined Agile values for your organization, who should you invite to the meeting to define them when you return?

5

2. Product Owner Engagement

6

§  As the product owner you own the vision and the final result!

§  You should be engaged full-time on a daily basis with the scrum team in order to increase the opportunities for effectively communicating the vision. »  In the ideal world you would be dedicated to one project, working with the team

about 6 hrs every day to help you achieve your goal. »  Half of your time will be spent in story creation meetings with the story authors,

and the other half will be consumed by time to think, create presentations for leadership, and socialize ideas with peers and subject matter experts.

»  If you cannot attend these sessions with your team every day, you need to make yourself available to resolve issues and answer questions.

»  Remember: If you have a scrum team that is delivering functionality at a disappointing rate, the first thing to change is the amount of time you spend with the team on a daily basis.

§  When the team begins to prepare for sprint one, you should plan to attend story creation workshops twice a day everyday for 1½ – 2 hrs each. »  Include story authors, an architect, and a user experience specialist as appropriate »  These workshops will go on almost until the end of the project, however you may

not need to attend these twice a day every day after the product backlog grows to an appropriate size (e.g. 2X the rate at which stories being consumed)

Engagement Exercise (example) §  How much time do you spend with your Scrum team on a daily

basis? »  If you were to spend 6 hours per day with your Scrum team, how

much of a productivity gain do you believe they would experience?

§  How available were you to answer those “quick questions” that your team came up with? »  Have you provided your team members with a preferred address (e.g.

phone, email, facebook, IM) for them to reach you and an SLA for responding to them?

§  Have you opened a direct line of communication to every member of your team? (i.e. no intermediaries or proxies)

§  If you are working with Product Owner Proxies (POPs), what limitations or advantages of this approach do you see?

7

3. Representing the Business

8

§  As the product owner, you are part of the scrum team »  To act as the voice of the customer »  To represent the interests of the business sponsor »  To steer the team toward producing the best possible outcome for your

peers in the end-user community

§  It’s your responsibility to know what you need to know that will help you accurately and effectively represent the voice of your internal or external customer. »  For external customers, you may need to engage other internal

departments (marketing, sales, etc.) or external focus groups to refine the vision.

»  For planning purposes, you have a key role in the release planning process, representing the business in setting priorities, and forecasting what stories should move downstream when.

3. Representing the Business (cont’d)

9

§  You are accountable to your sponsor and your peers for what is created. »  Earlier in the project, you need to be the advocate of the stories created by your

team, and review those with your sponsor and your peers frequently to improve them.

»  Halfway through, when you “change your mind” and want the team to rework something already completed, be prepared to justify that decision with your sponsor and peers.

»  Later in the project, you need to continuously “sell” the built product to your business colleagues to ensure acceptance by the end users.

§  As the representative of the business… »  When your peers need to know how they will be affected by the project, you

provide that answer. »  When the story authors need to know which story is more important, you

provide that answer. »  When the developers need a final answer on where something is placed on the

screen or what color the button is, you provide that answer. »  When testers need clarification on an item in the acceptance criteria, you provide

that answer. »  When release management asks when the product is going to production, you

provide that answer.

4. Authority to Adjust the Detail

10

§  While macro-scope items have been determined by the business case for the project, you have authority and you will be held accountable for decomposing those items into small units of work, i.e. the user stories, and prioritizing them. »  You are responsible for the micro-adjustments in scope, e.g. determining

when, where and how workflow steps appear on the screen, determining the color of the screens, and determining an acceptable wait time for a screen to refresh.

»  You are responsible for keeping up-to-date the list of detail scope items, i.e. user stories on the product backlog

»  You are responsible for prioritizing the product backlog according to business value and helping the team determine when certain scope items should be completed (via the release planning process).

»  You are responsible for ensuring that all user stories support the macro-scope as defined in the business case.

4. Authority (cont’d)

11

§  If you are working in a F500 company where the project/program leadership is actually a triumvirate (the product owner, technology lead, and QA lead), I assume that you will be savvy about always keeping other leads in-synch to avoid confusion. »  It’s your responsibility to coordinate with the technology lead and QA

lead on matters that may significantly change the scope, timeline, staffing, or budget of the project.

§  You will typically be expected to deliver presentations on scope, financial management, and delivery expectations to the sponsor and/or leadership committee, as well as lead demonstrations of the functionality to executives. Be prepared for this.

5. Approvals

12

APPROVAL OF STORY CONTENT

§  As the product owner, your participation in the story creation process is key to the success of the project.

§  You own the content of all stories that your team creates.

»  If you don’t like the way a story is worded, collaborate with the story author to adjust it.

§  Near the end of the story creation process, you have two steps that should not be skipped or delegated:

»  The “story review” with the product owner (prior to team estimation): the product owner collaboratively reviews the story with the story author, ensuring that it is in alignment with the macro-scope of the project and that the story represents your vision - for a particular aspect of functionality - at that moment. This may be informally done daily (preferred) or formal reviews held on a frequent basis. (This should never be viewed as a signoff.)

»  The “story review” with the end user / stakeholder / peer community : you and story authors host a meeting with the end user / stakeholders / peers from the business, to review the stories the team has recently created and ask for their feedback and content improvements before the developers build functionality for those stories.

5. Approvals (cont’d)

13

APPROVAL OF STORY FUNCTIONALITY §  As the product owner, you and/or the story authors need to review functionality for

the stories committed to in the sprint before the “sprint review”, a.k.a. the demo, and provide feedback to the scrum team members

»  You should be collaborating daily with your developers and testers, and frequently providing feedback to them about what they’ve created (both positive and negative).

§  The expectation is that – when you attend the sprint review meeting – you have seen and approved of the functionality that the team will show off to your peers prior to this meeting.

»  You need to feel comfortable demonstrating the functionality with an audience of your peers, stakeholders and sponsors. Why? Executives love demos. Our advice: be prepared!

§  Typically these approvals could be performed as a series of short 10 min informal get-togethers or through more formal meetings where functionality for groups of stories are reviewed in the last few days of the sprint.

»  If you don’t like the functionality or behavior of the system, provide specifics for the team as to what they need to change or improve prior to marking that story “complete”.

We recommend two things regarding story functionality acceptance: 1. …that you take a hard-line approach on approving functionality. Don’t accept it unless you

like what you see – both in terms of behavior and look & feel. 2. …that you are aggressive in asking the individuals on your team “when can I see the

functionality for story 346?”

SCENARIOS

14

Scenario #1: the unforeseen hurdle

15 © 2010, Cognizant Technology Solutions.

A project with two scrum teams is on day 7 (Thursday) of a 10 day sprint ending this coming Tuesday. The IT executive sponsor is a buddy of yours that you know well and play golf with occasionally.

An unforeseen technical hurdle was discovered today that’s going to require one of the two teams to put in an additional 30 hours of new tasks to overcome the obstacle. In order to avoid the weekend work and a potential sprint failure, the team has asked for options: either for the sprint to be extended by two days, the scope to be cut, or for an additional two people to be moved into their team temporarily.

The scrum master recommended against their request, and the team has approached you. Do you:

a.  Direct both teams to prepare for weekend work, extend the sprint by two days, fire the scrum master and dive in personally “to help”, and call the IT executive sponsor yourself to tell him the news.

b.  Supporting the Scrum Master’s recommendation, discuss consequences of the options with the teams. Tell them that they cannot extend the sprint, but allow them to determine which of the two remaining paths they will take and hold them accountable for it.

c.  Become angry when the teams ask to cut the scope for this sprint. Yell at team leads – tell them that cutting the scope is not an option, but allow them do determine which of the two remaining courses of action is appropriate.

d.  Walk away; direct them to figure it out on their own and not to bother you over the weekend if they work it.

e.  Supporting the Scrum Master’s recommendation, ask the two teams to collaborate on a solution and do “whatever it takes” to meet their commitment, but don’t allow them to extend the sprint, cut the scope, or add people.

Scenario #2: dependencies

16 © 2010, Cognizant Technology Solutions.

It’s September, and a scrum project in your area is building a new UI for a critical business need required for federal government compliance before the start of the new year. The project kicked off with a new team and they are now in sprint three. They are struggling but have made reasonable progress thus far. In a story estimation meeting discussion today, the team discovered that they have a dependency on two components, one being developed by waterfall project that was started six months ago that is just now starting its coding phase, and the other by a sister scrum project that is just starting sprint one. The component being developed by the waterfall project will not be ready for use for at least three months, and the sister scrum project is so new that they have no idea when they will get to it. The team has approached you for your thoughts. Do you recommend that they: a.  Reprioritize – call the head of the waterfall project and request that they re-prioritize their

work to meet the compliance need, then direct the product owner of the sister scrum project to prioritize work on the component the first scrum team needs first. If they are not able to do so, escalate the issue to your executive business sponsor.

b.  Call a team meeting – direct them to “do whatever it takes” to complete the UI and the components it needs, regardless of what other projects are developing. If they develop duplicate components of the others, so be it.

c.  Reorganize your people – pull the developers off of the waterfall project and attach them to your scrum project as a newly formed scrum team, then collaborate with the other product owner to fold the sister scrum project into yours. Direct them all to make the components to work for both the scrum and waterfall projects.

d.  Admit failure – call a meeting with the business and the legal group to let them know that we will not be able to meet the compliance requirement and to discuss your options.