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.