the product owner’s guide to the sprint retrospective

7/25/2019 The Product Owners Guide to the Sprint Retrospective

1/12

The Product Owners Guide to theSprint Retrospective

Written by Roman Pichler

on Tuesday 17th June 2014

SummaryThe sprint retrospective is the key mechanism in Scrum to improve the way people work. Some

product owners believe though that they should not attend the meeting, and if they do then only as

guests and not as active participants. But the retrospective does not only benefit the development

team and the ScrumMaster; it is also an opportunity for the product owner to learn and improve, as

this post explains.

The Retrospective in a Nutshell

The sprint retrospective is an opportunity to pause for a short while and reflect on what happened in

the sprint. This allows the attendees to improve their collaboration and their work practices to get

even better at creating a great product.

The meeting takes place right at the end of the sprint after the sprint review meeting. Its outcome

should be actionable improvement measures. These can range from making a firm commitment to


2/12

start and end future meetings on time to bigger process changes. The retrospective is not a finger-

pointing exercise. As Mahatma Gandhi famously said: Be the change you want to see in the world.

Take Part

As the product owner, you are a member of the Scrum team, which also includes the development

team and the ScrumMaster. While you are in charge of the product, you rely on the collaboration of

the other Scrum team members to create a successful software product. If you dont attend the

retrospective as the product owner, you waste the opportunity to strengthen the relationship and to

improve the collaboration with them.

But there is more to: Taking part in the sprint retrospective allows you to understand why the teamrequires some time in the next sprint to carry out improvements such as refactoring the build script,

or investigating a new test tool; and maybe more importantly, it helps you improveyour own work.

Say that some of the user stories the team had worked on did not get finished in the sprint. At first

sight this looks like the development teams fault. But analysing the issue may well reveal that the

size of the stories and the quality of the acceptance criteria contributed to the problem. As you are

responsible for ensuring that the product backlog is ready, this finding affects your work: It shows

you that you have to decompose the user stories further and it suggests that the development

teams involvement in getting the stories ready should be improved otherwise you would have

spotted the issue before the stories went into the sprint.

If you had not been in the retrospective would you then whole-heartedly support the resulting

improvement measures and change the way you work?


3/12

Be an Active Participant

Dont attend the retrospective as a guest who will speak when asked but otherwise remains silent.

Be an active participant, use the sprint retrospective to get feedback on your work, and raise any

issues that you want to see improved. Be constructive and collaborative but dont shy away from

tough problems.

Here are some questions that you may want to explore in the retrospective:

Do you spend enough time with the development team? Are you available to answer questions or

provide feedback quickly enough? Do you provide the right level of feedback and guidance in the

right way?

Is the communication between the team and you open, honest, and trustful?

Does the team know how the users employ the product?

Are the team members happy with their involvement in analysing user feedback and data, changing

the product backlog, and getting stories ready for the sprint? Do you get enough support from the

team to groom the backlog?

Are the team members aware of the big picturethe overall vision, the product strategy, and the

product roadmap? Do you get enough of the team members time to help you with product planning

and product roadmapping?

Improve the Wider Collaboration

As important as it is, continuously improving your collaboration with the development team and the

ScrumMaster is usually not enough. You also need strong relationships with all the other people


4/12

required to make the product a success. These include individuals from marketing, sales, customer

service, finance, and legal, as the following picture shows.

A great way to review and improve the collaboration with your partners from marketing, sales and so

forth is to invite them to the retrospective on a regular basis. Depending on how closely you

collaborate, this may range from once per month to once per major release. A joint retrospective will

help you develop closer and more trustful relationships, help smooth the launch of new product

versions, and improve selling and servicing the product.

Here are some questions that you may want to explore in an extended retrospective:

Are the partners from marketing, sales etc. involved enough in the product planning and

roadmapping activities?

Do they regularly participate in the sprint review meetings? Are the review meetings beneficial for

them? Do they understand the project progress?

Do they receive the information necessary to carry out their work in a timely manner, for instance, to

prepare the marketing campaign and to compile the sales collateral?

Do you get enough data and support from the partners, for instance, regular updates on the sales

figures and the market feedback you require?

You can, of course, also discuss these questions one-on-one. But getting any issues on the table

and discussing improvement opportunities creates a sense of we-are-all-in-this-together; it reaffirms

the need for collaboration and teamwork to provide a great product; and it can break down

departmental boundaries.


5/12

Learn More

You can learn more about the sprint retrospective meeting and the product owner by attending

myCertified Scrum Product Owner training course.Pleasecontact meif you want me to teach the

course onsite or if you would like me to run a product owner workshop at your office.

Source:http://www.romanpichler.com/blog/product-owner-sprint-retrospective/

Subscribe to Roman's blog & receive email updates

Email

Subscribe

Tags related to this postlearningproduct ownerscrumScrumMasterstakeholdersteamwork

12 comments on The Product Owners Guide to the SprintRetrospective

1.

Mark Levison

June 20, 2014 4:37 pm

Romaninteresting post. I do remind POs to be careful when their relationship with a team

is new there is a balancing act to be played when they are present at the retrospective.
http://www.romanpichler.com/training-courses/certified-scrum-product-owner-course/http://www.romanpichler.com/training-courses/certified-scrum-product-owner-course/http://www.romanpichler.com/training-courses/certified-scrum-product-owner-course/http://www.romanpichler.com/contacthttp://www.romanpichler.com/contacthttp://www.romanpichler.com/contacthttp://www.romanpichler.com/blog/product-owner-sprint-retrospective/http://www.romanpichler.com/blog/product-owner-sprint-retrospective/http://www.romanpichler.com/blog/product-owner-sprint-retrospective/http://www.romanpichler.com/blog/tag/learning/http://www.romanpichler.com/blog/tag/scrum/http://www.romanpichler.com/blog/tag/stakeholders/http://www.romanpichler.com/feedhttp://www.romanpichler.com/blog/tag/stakeholders/http://www.romanpichler.com/blog/tag/stakeholders/http://www.romanpichler.com/blog/tag/scrum/http://www.romanpichler.com/blog/tag/scrum/http://www.romanpichler.com/blog/tag/learning/http://www.romanpichler.com/blog/tag/learning/http://www.romanpichler.com/blog/product-owner-sprint-retrospective/http://www.romanpichler.com/contacthttp://www.romanpichler.com/training-courses/certified-scrum-product-owner-course/


6/12

They may have a bigger title and represent powerthey have to ask how the team will

respond to this.

The team may have significant issues with the way they work especially in the first few

sprints. How can they make their openness to feedback clear.

If the team decide to take on an improvement that they dont want they have ask if it is in

their position to comment.

Example of the latera few years ago I had a very new, very aggressive PO working with a

young team. The team were discussing improving their Engineering Practices (trying TDD in

this case) and the PO said I hear TDD is very powerful and thats cool. However I have a

very important release coming up in three sprints please dont practice TDD before then. As

you can imagine those comments had a chilling effect on the team, not just wrt to TDD but

also one morale. The release took alot longer then three sprints and the team took alot

longer to build the momentum and drive they needed.

So I like having my POs involved in the Retrospective as long as they remember the Dev

Team own how to achieve the goals the PO sets out.

REPLY

2.

Roman Pichler

June 23, 2014 11:56 am

Hi Mark, Thanks for your insightful comment. I find that product owners benefit from having a

ScrumMaster who provides guidance on how to play the product owner role effectivelyto

make product decisions and to act as a team playerwho suggests ground rules for the

retrospective, and who prepares and facilitates the meeting. The latter may mean talking to

the product owner beforehand to make him or her aware of what the retrospective is all

about and to kindly remind the individual during the meeting to respect the ground rules. If a

product owner is not willing or able to effectively collaborate with the dev team, then this

should be addressed in the next retrospective. Do you agree?

REPLY
http://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6452#respondhttp://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6452#respondhttp://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6457#respondhttp://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6457#respondhttp://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6457#respondhttp://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6452#respond


7/12

o

Mark Levison

June 24, 2014 9:22 pm

RomanI think were on the same page, I just wanted to play a counterpoint.

My general approach is do a safety check, possibly a blind safety check. Prompt question

might be Team would you be as open and honest as necessary if our PO was present.

If the answer is affirmativefantastic. If not I would use it as a discussion point in the

retrospective. My question would be: What would we need to do establish sufficient trust

with our PO to invite to a future retrospective.

REPLY

Roman Pichler

June 27, 2014 9:25 am

Sounds great. Thanks for sharing your approach!

REPLY

3.

Michael Duxbury

June 23, 2014 1:44 pm

MarkIf I understand you correctly, youre saying those three situations are where you may

not want a PO in a retrospective.


8/12

But to me, theyre all really good cases of where the PO *should* be in the retrospective if

for no other reason than to counteract the fears you raise.

They may have a bigger title and represent power they have to ask how the team will

respond to this.

If this is the case, not being in the retrospectives (being elusive) will only add to this feeling.

The PO should be there, making the team feel at ease.

The team may have significant issues with the way they work especially in the first few

sprints. How can they make their openness to feedback clear.

Again, if the PO attends and is supportive, thats a much better message to give off. If the

PO isnt made aware of significant issues early on, that sounds like a big problem waiting to

happen.

If the team decide to take on an improvement that they dont want they have ask if it is in

their position to comment.

This is the most interesting one; in your example, the PO should be there *precisely

because* the team wants to try TDD. That way they can work together on a plan. In my

opinion, if would be perfectly reasonable for the PO to say, thats a great idea, but maybe

not so close to the release, and elicit feedback from the team. Perhaps theres a reason why

now is the perfect time; perhaps the team compromises and everyone agrees TDD should

be trialled in three sprints time; perhaps they decide to timebox some initial research in the

upcoming sprints. The point being, how could something like this be discussed *without* the

PO being in attendance?

What you may have been saying, of course, is that POs shouldnt attend retrospectives if

theyre not very good POs

REPLY

o

Mark Levison

June 24, 2014 9:25 pm
http://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6458#respondhttp://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6458#respondhttp://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6458#respond


9/12

Michaelas I just replied to Roman Im saying that there may be times early in a teams

existence when the trust hasnt yet been established. If ithasnt then its important to

establish rapidly.

REPLY

4.

theronkelso

June 27, 2014 2:28 pm

RomanIt seems that too often, retrospectives focus on the Development Teams process,

relationships, and tools. Your post here does a great job of addressing the need to address

relationships across the entire Scrum team, including the extended team. What I see missing

is that tools and processes for the entire Scrum team need to be addressed. If TDD is a valid

topic for a PO to engage in, which I believe it is, then so is Lean UX user research and/or

choice of wireframing tools is equally valid topics for the retrospective.

How do we make the retrospective process more inclusive of discovery type processes,

relationships, and tools?

REPLY

o

Roman Pichler

June 27, 2014 4:05 pm

Hi Theron, Thanks for your comment. Its a great idea to look at discovery practices in the

sprint retrospective. But remember that Scrum is essentially a solution validation tool, a

model that helps teams build a great producta product with the right features and the right

UX. Problem validationfiguring out the target market, the value proposition, the business

goals and modelis not supported by Scrum. As a consequence, teams should start Scrum

once they have successfully performed problem validation. For major updates of existing


10/12

products, teams may have to stop doing Scrum to do some research and validation and then

do Scrum again to develop the update, or to do both in parallel (if thats feasible). Discussing

these options is something that could and probably should be done in the retrospective. Do

you agree?

REPLY

Theron

July 1, 2014 2:07 pm

Roman, Makes sense. Were trying to do discovery in parallel to scrum and trying to use

retrospectives to improve the ongoing discovery work processes as well. Has resulted in:

they need to get better ay X, or thinking is silos so far. Is there a way to do retrospectives

across Discovery -> Delivery?

(Interested in your thoughts on the best way to inspect the work products from Discovery as

well. Is there demo of validated experiments?)

REPLY

Roman Pichler

July 1, 2014 4:05 pm

Hi Theron, I would suggest to explore how well running the two activities in parallel works for

you. You may find that it is more beneficial to focus everyone on discovery if the

discovery/validation effort is significant, for instance, when creating a major product update

that addresses a new market segment.

I like to timebox the validation work, for instance, to one month. I also like to review the

progress on a weekly basis based on the Vision Board/Lean Canvas/Business Model

Canvas/Javlin Board or whatever tool is used to capture ideas and insights. I like to


11/12

understand how many risks/assumptions have been addressed/validated and how many

crucial risks and how much uncertainty is left on the board/canvas.

Does this help?

REPLY

5.

Product owner

July 21, 2014 2:28 pm

It is very imperative for the PO to attend the retrospective. The sprint retrospective is

fundamentally a stakeholders event, and since the PO represents the stakeholders interests

in the project, he or she should ideally remain present in the meeting. Besides the official

presence of the PO, the retrospective offers a unique opportunity to discover the clients

mindset, and avail an inner understanding about the project as well as the clients

expectations and project vision.

REPLY

6.

Scrum tool

July 30, 2014 6:50 am

I guess if the team is encouraged to participate in an overt manner during the retrospective,

and if the PO takes the initiative to suggest new ideas and ways to improve, it might just get

the team members to open up and participate in a more fruitful manner. The retrospective

is important for a number of reasons, and one of the primary reason is for the PO to envision

and suggest new changes to improve the current workflow and process. His or her

attendance is essential in the retrospective.

REPLY
http://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6547#respondhttp://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6547#respondhttp://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6690#respondhttp://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6690#respondhttp://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6697#respondhttp://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6697#respondhttp://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6697#respondhttp://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6690#respondhttp://www.romanpichler.com/blog/product-owner-sprint-retrospective/?replytocom=6547#respond


12/12

Read morehttp://www.romanpichler.com/blog/product-owner-sprint-retrospective/
http://www.romanpichler.com/blog/product-owner-sprint-retrospective/http://www.romanpichler.com/blog/product-owner-sprint-retrospective/http://www.romanpichler.com/blog/product-owner-sprint-retrospective/http://www.romanpichler.com/blog/product-owner-sprint-retrospective/

the product owner’s guide to the sprint retrospective

Documents