Product Owner: Iteration Retrospective

Iteration Retrospectives are the structured reflective practice to learn and improve based on what has already been done. The purpose of retrospection is to examine the process the team uses, to build team commitment, and to transfer knowledge to the next iteration and possibly to other teams.

Retrospections must be done at the end of every iteration. A briefer version, the After Action Review can be done at any time, whenever there is value for the team to stop and learn from what has been done and change while it still helps work.

Why to do this practice

During each iteration, during every activity, the people doing work should help each other think about quality issues. Be explicit about what is required without trying to solve the problem (which is the responsibility of people who will receive stories or tasks to do).

Improving quality involves discipline and mutual commitment. Lean techniques – such as retrospections, keeping a clean environment, testing, and a correct use of patterns and code quality – help, but only when the team uses them regularly.

One of the principles of Lean-Agile is to create knowledge. Team Agility Masters should be sharing lessons (sanitized if need be) with fellow Team Agility Masters through their community of practice. In fact, this should be part of the assessment of their performance.

Who does this practice

Here are roles involved in this practice:

  • The whole team is involved in the retrospection. The retrospective is primarily for them.
  • The Team Agility Master is the facilitator for the retrospective. See Facilitate the Iteration Retrospective.
  • The Product Owner may be involved. See Facilitate the Iteration Retrospective for considerations.
  • Management and other outsiders may participate if their contributions and insights could help the team improve.

What to do

Inputs

Inputs to the retrospective include:

  • Team availability. The essential prerequisite for a retrospection is that everyone who was involved in the iteration be available. The reason is that everyone has some viewpoint about what happened. If someone is missing, an insight will be lost.
  • Facilitation plan. The Team Agility Master has prepared to facilitate the meeting.

Approach

At the end of each iteration, the whole team conducts a retrospection, facilitated by the Team Agility Master. The key question is, “If we could do it again, what would we keep doing and what would we improve?

To answer this, the team discusses the following:

  1. How well did we do in the iteration? Did we meet the iteration goals?
  2. How is the project progressing?
  3. What were your successes? (ask everyone)
  4. What processes / techniques would be good to use again?
  5. What were your challenges? What could have gone better? (ask everyone)
  6. What processes and techniques need to be improved?
  7. How is the team being? Are they raising impediments? Are they adjusting?
  8. What impediments are still present?
  9. On a scale of 1-10, what is the score of this iteration?

Some organizations boil these down into three broad questions: “What?”, “So What?”, and “Now What?”

The retrospective should be facilitated. See Facilitate the Iteration Retrospective.

Outputs

The Iteration Retrospective should result in one to three stories for the next iteration reflecting a “vital few” improvements to the process

When to do this practice

Here is when to do this practice:

  • At the end of every iteration, after the Product Demonstration.

The Iteration Retrospective should be time-boxed to 30 minutes.

Where to do this practice

Here is where to do this practice:

  • In a room that is convenient to the entire team

Outcomes

The benefits of this practice include:

    • A focused set of improvements that can be immediately put into practice.
    • Building a habit of improvement. The team as a whole and individuals on the team get in the habit of looking for ways to improve.
    • The team builds a sense of ownership for their processes.

Impediments to progress that are outside of the team’s control are naturally escalated to management and others who can do something about them.