Ways of Working Review – Are We Getting Better?
Team that has just finished a Sprint. Most User Stories are Done. There are no major incidents, and the release is still on track.
Do we really need a Ways of Working Review (Retrospective)? Team decides to skip it.
In the next Sprint, testing is again pushed to the last few days. Developers wait for requirement clarification. Several stories are carried over to the next Sprint.
Nothing is seriously wrong.
But the same things keep happening.
-> That is where a Retrospective creates value.
A Retrospective is not simply about asking: “Was the last Sprint good or bad?”
It is about learning from what happened and deciding what to improve next.
| Look Back | Purpose |
|---|---|
| What worked well? | Keep doing it |
| What did not work well? | Understand why |
| What keeps happening? | Find what needs to change |
| What will we do differently? | Agree on 1–2 concrete actions |
For example, instead of simply saying: “Testing was late again.” Team could agree:
“From the next Sprint, a story will only enter development when the acceptance criteria are clear and the tester has reviewed them.”
That is the real value of a Retrospective. It does not need to be a long meeting. And it does not need 20 action items.
The goal is simple: Make the team a little better after every Sprint.
If a Retrospective only talks about the past, it is just another meeting.
If it changes how the team works in the next Sprint, it becomes continuous improvement.
.png)