Skip to content
Home » Blogs » Artem's blog

Product owner on retrospectives

June 4, 2007 by Artem

Retrospectives initially were not a part of Scrum at all. There was supposed to be a retrospective part during the sprint review. Over the time it evolved into two separate sections: Sprint Review focused on what and Sprint Retrospective focused on how.

Since Sprint Retrospective is mostly devoted to the internals of the process, typically the product owner participation is useful as much as he is perceived as the everyday team member. There are teams that are colocated with the product owner and interact with him daily. In this case it might be useful to discuss the everyday practices with him. On the other hand there are teams that see their product owner once per sprint only. In this case often it would be useless or even harmful to invite the product owner to the retrospective. However, sometimes there are management related actions and requests expected as the retrospective outcome. In such situation PO's participation is needed as much as he is the interface to the management and as his approval/sponsorship is required for making a change.

Some teams feel comfortable with inviting him, some not. In any case retrospectives are for the team and they are to decide on what they are more comfortable with.

What is the situation in your team? Is product owner usually present on your retrospectives?

Bookmark/Search this post with:
  • Delicious
  • Digg
  • StumbleUpon
  • Propeller
  • Reddit
  • Technorati
Permalink

Comments

Retrospectives

June 8, 2007 by Alexey (not verified), 1 year 30 weeks ago
Comment id: 176

Hi Artem,

Our product owner is definitely present at such retrospectives.
Moreover he actually quite often the one to initiate and organize them.

What kind of aspects and key performance indicators are you usually discussing?
Check out my post on this topic

And this one also is related to your topic I think:

Thanks,
Alexey

Feelings

June 9, 2007 by Artem, 1 year 30 weeks ago
Comment id: 177

Our performance indicators are more about what we feel makes us faster or slower, less about the productivity numbers. For example, one retrospective originated action was to get a more clear strategy from the top management, because we felt somewhat confused about what the real company priorities in our area are.

In fact I am always a bit suspicious about the planned/reported/done hours you are talking about in your post. Tracking it might improve the team estimation skills, but it has to be done very carefully and only if the team wants to track it. Otherwise it's too easy to use the KPIs as a command'n'control tool (that's by the way easy to game) and it can decrease the trust level quickly.

more comments

June 11, 2007 by Alexey (not verified), 1 year 30 weeks ago
Comment id: 178

I agree with you, your team will probably figure out its velocity overtime even if you do not gather 'planned/reported/done hours' statistics. And everyone has to be supportive of this practice otherwise people will find ways to abuse the system. In my post I was just listing capabilities of our release management tool. Some of our users do pay attention to those. I personally like to drive our preliminary plan generator with those average numbers, to get a quick starting plan for our next iteration.

More important retrospective is probably customer/stakeholder feedback on the new version of your software because it eventually drives your priorities for the next iteration. Plus ease of communication within your team because that is the key to successful agile process.

Hey, what tools are you using to support your agile process?

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <b> <i> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <br> <blockquote>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. Beside the tag style "<foo>" it is also possible to use "[foo]".

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.

Best of AgileSoftwareDevelopment.com