Project Management


last edited by: Antonio Villarruel on Mar 25, 2022 10:25 AM login/register to edit this page
Keywords: Knowledge and Skills PMI-ACP Retrospective

1 Overview
2 Importance
3 PMI-ACP Exam Outline Reference
4 History
5 Current practice
   5.1 Example Process
6 See also
7 Sources & Reference
8 External Links


The Retrospective completes an Agile Iteration and is a vital part of the Agile Feedback Loop. Team and Product Owners usually are stating and demonstrating value created during the last iteration and discuss what went well, what could be improved upon and how. This phase is comparable with the "lessons learned" process during the closing phase of a regular project following the PMBOK at the very end of a project where depending on the duration of that project remembering and stating those issues might be difficult.

The Retrospective at the end of every iteration gives the opportunity to adjust the process more frequently and when memory is still fresh and utilize proposed improvement measures for the next iteration and therefore for most of the remaining life cycle of the project. Instead of stating what we could have done better in an Agile Environment, we adjust our process immediately.


Retrospective might be the most important part of the Agile process. Accepting the fact that scope will change continuously in an Agile project Retrospective helps keeping the team and product owners adapting to the steady stream of changes and focused on the promise of delivering value and avoiding waste. The phrase "fail often and early" in Agile indicates that we deliberately try to adapt with our process to steadily changing requirements and are aware that we could fail, but recognizing the deficiencies during our Retrospective we have the opportunity to improve our process and with it team efficiency and value delivered.

PMI-ACP Exam Outline Reference


Historically a Retrospective was recommended to be performed at the end of a project during the closing phase.

Difficulties to remember issues and their solution after time had passed during a longer project, fatigue of the project team that often had been going through the hardest and most exhausting phase of the project to complete and deliver and the starting process of team dissolution often prevented this process at all, cut it short or made it less efficient.

Criticism and potential conflict was often avoided knowing that a team member might not be on the next project in the same team and realizing that "lessons learned" could only have impact on the next project, but not change the outcome of the current one. For the same reason, it might have been very difficult to get stakeholders and sponsors involved.

Current practice

Iteration or Sprint Retrospective is commonly performed in a time-boxed and public meeting. Attendance of team and product owners is mandatory, stakeholders and customers often are invited for product demonstration and status reports or might just attend when their schedule allows for it since the meeting is public and on a fixed schedule.

Since team and product owners might talk on a very personal level about conflicts in the team, between team and product owners or between product owners and the intent to improve on the process often includes criticizing individuals, that (vital) part of the meeting is usually not public and separated from the first part.

Iteration Retrospective and Iteration Planning often are scheduled "back to back" to smoothly transition into the next iteration and potentially save meeting time for team and product owners.

It is generally recommended to keep both meetings separately time-boxed and when performed back to back not to exceed 2 hours total (with a break) to keep attendees attentive and focused.

Commonly Retrospective and Planning are time-boxed one to two hours each. It is recommended to separate the two meetings initially to emphasize the importance of both and prevent unintended merging, or when later combined time would not allow to perform all tasks in due time and length or the combined meeting time would exceed two hours.

Since the Retrospective meeting is held after every iteration at the same time and at the same location it is often used and referenced updating users and stakeholders on the project progress. This might offer a powerful opportunity to include those groups into the project feedback loop and create ownership for the project on a broader base.

Agile Teams commonly spend less time with Retrospectives the longer they work together and the further they are along in a project since their process has evolved and improved from iteration to iteration, hence the common desire to combine Iteration Retrospective and Iteration Planning in one meeting.

Example Process

Step 0: Display Kerth's Prime Directive (for a retrospective) on the wall where all participants can read.

Regardless of what we discover, we must understand and truly believe that everyone did the best job they could, given what was known at the time, their skills and abilities, the resources available, and the situation at hand.

Step 1 (5 min): Team safety check: Each team member anonymously writes down a number between 1 & 5 on a post-it note. All post-it notes are collected and stuck on the board in front of the group. The number represents how "safe" each team member feels to express their true feelings in the room at this time, with these people. The aggregated result determines how the team should interpret the remaining discussion in the retro. The definition of each number is as follows:
1) I'll smile and claim everything is great and agree with the managers
2) I'm not going to say much. I'll let other bring up issues
3) I'll talk about some things; other things will be hard to day
4) I'll talk about almost anything. Some things might be hard to say
5) It's no problem. I'll talk about anything

Step 2 (10 min): Team brainstorming under the following 3 headings:
- What went well (that if we don't discuss we might forget)? Happy Face
- What should we do differently next time (what lessons did we learn)? Unhappy face
- What still puzzles us? Puzzled Face

Using a whiteboard or butchers paper, each team member takes a pen, gathering around in a scrum and brainstorm method ideas under each of the three headings. No discussion allowed.

Step 3 (10 min): Review each of the three lists one item at a time. Each team member who wrote the item can elaborate on the intent & meaning (less than 1 minute per item). Questions of clarification are fine, but no discussion is allowed.

Step 4 (5 min): Voting: Each team member takes a pen, gathers around in a scrum and votes for items that he feels are important and warrant further discussion. Various voting techniques can be applied; the simplest is to allow each team member to vote as many times as they want, but not for the same item more than once. Sum the votes and identify the top 2 or 3 items. No discussion allowed.

Step 5: (balance of your time - 25 min) Discuss each of the top voted topics.

Step 6: (5 min) Document & confirm actions, owners and due dates. Share this list with the team (via email, SharePoint, Visual Management, etc)

Follow-up: The team holds each other accountable for ensuring actions are completed.

See also

Sources & Reference

External Links

Agile Retrospective Resource Wiki
The Retrospective Starfish
A Retrospective Timeline

last edited by: Antonio Villarruel on Mar 25, 2022 10:25 AM login/register to edit this page

Comments (1)

Login/join to subscribe

"It is hard to fight an enemy who has outposts in your head."

- Sally Kempton