I was reading a blog post from a coach who was working with a continuous deployment team. In essence, every story (work item, PBI, etc.) from their sprint made it into the customers hands immediately. They received feedback on each in real-time and took follow-up actions as appropriate.
Since they were using Scrum, they were still conducting a Sprint Review every few weeks. The coaches question related to the value of the review. As it seemed that everyone was questioning it in this particular context. That is, since they saw (and accepted) things in real-time, what was the need to see them again in a review? Or were they just doing it because the Scrum Guide said to do it?
And the backstory was that the coach was struggling with dogmatic Scrum in the organization. I.e., doing things just because the book said to do them, rather than thinking and adapting.
This question made me think a bit about Sprint Reviews. And it led to the following online response to that coach –
My reply
For years and years, I’ve been talking about the importance of Sprint Goals in the fabric of Scrum team execution. They:
- Help to guide the focus and conversations at the daily standup and the team’s daily activity;
- Help to focus the team’s sprint planning towards an outcome;
- Help to identify the purpose and focus of the sprint demo;
- Help the Product Owner and the team in making sprint content trade-offs if the run into difficulties;
- Ultimately help the team define what “success looks like” for each and every sprint.
Given that definition, my clients usually start looking at Sprint Goals in a different way. I see them as being very powerful mechanisms for focusing the team’s efforts and I hope you start to as well.
I wrote an article a few months ago about sprint reviewing the “hard stuff”. It was inspired by an engineer who asked me (challenged me) about demonstrating more back-end, embedded, non-UI, infrastructural work at the end of Scrum sprints.
His general take was that it was:
- Hard to figure out how to demo the “stuff” they were delivering, and
- The components didn’t lend themselves to demonstration (in simplistic terms, they didn’t have a UI)
I pushed back a bit in the article, trying to encourage him to demo “something” and not “go silent” for too long.
I honestly believe that having high-energy and high-impact Sprint Reviews truly differentiates high-performance agile teams and organizations. It's very much of a "Show Me the Money" moment for the team. It allows the team to be transparent and demonstrate their results. It allows the organization to provide feedback. And it serves as a progress baseline / milestone so as to measure progress towards established goals. And finally, it should be cause for "celebration".
In many ways, agile delivery is about Earned Value, and EV is demonstrated one sprint at a time.
Recently a young engineer stopped me after a class I shared at a national conference and was asking questions. The context in this case was this:
We were talking about the importance of having “dynamic” Sprint Reviews that engaged the organizations stakeholders and customers. How showing “working code” was important for the team to show progress towards their Sprint Goals and commitments.
In this particular case, the client organization was delivering more API level software to their internal customers. They were being asked for system-level functionality in some communications equipment and would implement low-level code to meet the requests. They would expose the User Stories functionality via API calls.
