'Agilizing' Sprint Reviews

Hola amigos! Sunday! Tip:I prefer to think that this is the first day of the week rather than the last one! However while you are on leave, you will feel that there are no Mondays :-) Awesome!

Anyway. Today I was thinking about the "Sprint Reviews". By the way, not sure if I have already linked you to Mountain Goat Software website before in here. This is Mike Cohn's company - one of the co-writers/co-signers of the Agile Manifesto. Absolutely recommendable for quick checks on Scrum/Agile topics. Surely 

Sprint Review. This is the "demo" where we demonstrate how good we did within the sprint. Right?  I assume everybody knows about it so I'll stick to the main point.  
Why do we do sprint reviews? This is the first question we need to ask ourselves. So, doing a bit of brainstorming:
- To encourage the team to feel part of the sprint delivery via presenting their product. So to speak, increasing the team spirit.
- To demonstrate the product owner/stakeholders/customers the goals met within the sprint.

And this always the last (or almost last) meeting of the sprint. So, let's bring an extreme example. A 4 weeks sprint. The product owner defines the priorities and the first priority item is taken by the team on the first day of the sprint. This is quite small one. The definition of done is achieved in a day. The time goes by... We go ahead picking up other items. We reach the last day of the sprint. OK, let's start the sprint review. Can you hear the magic words?

"This is definitely NOT what I want"

If something has been completed in the very first day, why do we have to wait for the very last day of the sprint to show & tell about it? Although the effort on defining the meeting as an informal one, where we shouldn't spend more than 2 hours to prepare it, where we should not bring slides, are we really anticipating changes when we perform this meeting at very late stage? Are we really responding to a change? Is this Agile? Does not sound a bit to Waterfall? Yes, the evil waterfall. 

I propose a new model that could be more effective. An incremental one. Once the story is "shippable", let's try to show it as soon as possible. Let's not wait until the last minute. Just after the story is completed, we would arrange a small catch-up. As in a Kanban Board, we can move the ticket to a "Ready to Show" status and we could perform small incremental sessions so we can confidently reach the completion of the sprint with a higher level of satisfaction. It requires more communication - as in Agile compared to Waterfall - but it ensures a better quality.

                                                        "This is definitely what I want"

Shiny sprints :-)


Popular posts from this blog

Agile in wine shops