Process Improvement Retrospective

Pick one process apart and decide what to change.

Try this retrospective live

Process Overview

What is the current process we're reviewing?

The process for onboarding new employees involves multiple steps across different departments.
Our software development lifecycle includes requirements gathering, design, coding, testing, and deployment phases.
The procurement process encompasses vendor selection, contract negotiation, and order fulfillment.
Process Purpose

Why does this process exist? What is its intended goal?

The onboarding process aims to ensure new hires are properly integrated into the company culture and equipped with the necessary tools and knowledge.
Our software development lifecycle is designed to deliver high-quality, well-tested products that meet customer requirements.
The procurement process helps us secure the best value for our organization while mitigating risks and ensuring compliance.
Pain Points

What challenges or issues are you currently facing with this process?

The onboarding process is often delayed due to miscommunication between departments, leading to a poor first impression for new hires.
Our development cycle frequently encounters bottlenecks during the testing phase, causing delays in product releases.
The procurement process can be time-consuming and inefficient, with redundant steps and excessive paperwork.
What's Working Well

What aspects of the process are effective and should be retained?

The initial orientation session gives new hires a thorough overview of our company culture and values.
Our development team is good at gathering and documenting requirements, so everyone understands the project goals.
The procurement team has established strong relationships with key vendors, enabling efficient negotiations.
Improvement Ideas

What changes would make the process work better?

A single onboarding portal would give every new hire the same information and cut down the back-and-forth between departments.
Introducing automated testing tools could accelerate the testing phase and reduce manual effort.
Digitizing procurement documents and using e-signatures could significantly reduce processing times.

What is a Process Improvement Retrospective?

A Process Improvement Retrospective is a meeting where your team reviews one specific process, such as onboarding, code review or procurement, and decides how to make it work better. Where a sprint retro covers everything that happened recently, this one stays on a single process from start to finish. The board has five columns, worked through in order. Process Overview gets everyone describing the same process, step by step. Process Purpose asks why it exists and what it's meant to achieve, which often shows that some steps no longer serve that goal. Pain Points collects the delays, rework and frustrations people run into. What's Working Well names the parts worth keeping, so you don't throw them out with the rest. Improvement Ideas is where the team suggests changes and picks the ones worth trying. Because people from different roles see different parts of a process, the review works best with everyone who touches it in the room. Run it when the same problem keeps recurring, a few weeks after a new process goes live, or on a regular schedule for the processes your team depends on most.

Process Improvement Retrospective Format

Process Overview

What is the current process we're reviewing?

Start by describing the process at a high level, step by step, so everyone is reviewing the same thing. If people describe it differently, write that down; it's often the first pain point.

Process Purpose

Why does this process exist? What is its intended goal?

Ask why the process exists and what it's supposed to achieve. Agreeing on the goal makes it easier to spot steps that no longer serve it.

Pain Points

What challenges or issues are you currently facing with this process?

Make it safe for people to share their frustrations and concerns openly. Ask for specific examples of delays, rework or confusion, not general complaints.

What's Working Well

What aspects of the process are effective and should be retained?

Ask which parts of the process work well and should stay. Naming them now keeps the team from losing them when it makes changes.

Improvement Ideas

What changes would make the process work better?

Invite ideas for changes, from small fixes to bigger redesigns. Then have the team pick the ones with the best mix of impact and effort.

When to use this retrospective

  • When the same issues or delays keep showing up in an existing process
  • A few weeks after you introduce a new process, to check it's working and decide what to adjust
  • On a regular schedule for the processes your team relies on most
  • When people disagree about how a process is supposed to work, or why it exists

Suggested icebreaker questions

  • If you could redesign the process from scratch, what would be your first step?
  • Share a humorous or frustrating experience you've had with the current process.

Want a warm-up your team plays, not just answers out loud? Browse free icebreakers →

Ideas and tips for your retrospective meeting

  • Make it clear you're reviewing the process, not the people who run it, so feedback stays honest
  • Invite people from every role that touches the process; each one sees a different part of it
  • Sketch the process as a simple map or flowchart before the session so bottlenecks are easy to point at
  • Rank improvement ideas by likely impact and effort, and pick the top one or two
  • Give each agreed change an owner and a date
  • Book a short follow-up to check whether the changes worked and adjust if they didn't

Frequently asked questions

What is a Process Improvement Retrospective?
It's a retrospective focused on one process instead of a whole sprint. Your team describes the process, agrees on its purpose, lists pain points and what works, and then chooses specific improvements.
How do you run a Process Improvement Retrospective?
Work through the five columns in order, starting with a shared overview of the process. Add notes privately, group and vote on the pain points, then turn the top improvement ideas into actions with an owner.
When should you run a Process Improvement Retrospective?
Run one when a process keeps causing the same problems, a few weeks after a new process goes live, or on a regular schedule for the processes your team depends on most.
Who should attend?
Everyone who takes part in the process, including people from other teams who hand work in or receive it. Each role sees different pain points.
How is it different from a sprint retrospective?
A sprint retrospective covers everything from the last sprint. A Process Improvement Retrospective looks at one process in depth, including whether it still serves its original purpose.

Related templates

WWE Smackdown Showdown Retrospective

Tag-team your sprint review with a wrestling theme.

Working, Not Working Retrospective

Sort what's working from what isn't, then fix it.

Quarterly Retrospective

Step back from the sprints and review the whole quarter.

Baby Steps Retrospective

Pick one small change your team will actually finish.

Ready to run this retrospective?Try this retrospective live