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 a strong advocate of goal-setting within your agile teams. Ares where I think goals are important include:
- At the daily stand, focusing the conversations towards the teams' goals;
- During sprint planning and at the sprint review, focus towards the sprint goal;
- If you're doing releases, ala SAFe release trains or a similar mechanism, then having a release-level goal is important;
- To me, Definition of Done and Definition of Ready, are goal-oriented. Providing clarity on the teams' constraints;
But...
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 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.
This update is from the STP conference I’m attending in Denver the week of November 3, 2014. Software Test Professionals is a conference mostly focused towards testing, so the slant of all of the talks is that lens or perspective. That being said, the agile topics are by definition broader and more whole-team centered.
I just attended a session by Jeff Porter where he was exploring agile practices in a talk entitled: Agile – Where the Rubber Hits the Road.
Now let me start by saying that I liked Jeff’s talk. It was very pragmatic and practical. He simply shared what they were doing at FamilySearch.org. Practitioner reports like this one truly enhance the state of practice in the agile community.
Introduction
There are several terms used for it within agile contexts. Sometimes you hear:
- Done
- Definition-of-Done or DoD
- Done-Ness Criteria
- Acceptance Criteria
- Release Criteria
Sometimes you even hear it repeated, as in: This story isn’t complete until its—“Done…Done…Done”.
Apparently the more “done’s” you have, the more emphasis there is on completeness. Although I don’t think I’ve heard more than four “done” used in a row.
