Your team starts a 2-week sprint. You have the sprint kick-off ritual, they commit to a bunch of tasks, and off you go. Putting aside the actual delivery of the tasks, ten workdays have gone by, and now you’re at the end of the sprint. You might have a quick retrospective ritual to come up with some excuses for why things weren’t done on time (“I was sick,” “Product didn’t break this down enough,” and, my favorite, “It’s done, just not deployed”). Regardless of the validity of these reasons, you celebrate that another sprint is done and the process repeats itself. This is groundhog-sprint.

Teams that don’t deliver well have many reasons to burn out as these cycles happen, but even teams that seem to get everything done every sprint often don’t find this fulfilling enough. I regularly hear about engineers wanting to be promoted, switch teams, or get more responsibility at a faster and faster pace. Some of it undoubtedly stems from not feeling self-actualization from the work they are doing.

What’s lacking, usually, is closure. Why did you invest those two weeks in those specific tasks? Did it have any significance? What’s the impact? While some people are motivated simply by the feeling of getting tasks moved to the “Done” column, for a lot of people, this is not enough over a certain period of time.

Instead of having retrospectives only for the delivery portion, have Meta-Reviews. Measure whether the feature and work have had the expected impact and whether it was a good investment of effort. (These are a good idea regardless of the morale of the engineering staff, by the way.)

Share these results with the team. If your hypothesis was wrong, state it. If it turned out to be a success, celebrate it. Show them the positive client emails, the improvements in Sales KPIs, the lowered churn, the higher conversion. They’re not writing code for the sake of writing code. Connect them to the business.

Doing this is a required part of cultivating Product Mastery, and connects well to effective goal setting a-la OKRs.