One evening I was having drinks with some colleagues after work and, as should come as no surprise, the topic made its way to Scrum – more specifically, what was the best advice we’d ever heard on the subject.
“If your team looks good, you look good,” said Oscar looking around the circle for approval. We all nodded in unison as it became Lin’s turn to chime in.
“Always experiment with your process- nothing is permanent.” Another piece of sage advice we collectively agreed with, as Phil tried to flag down the waitress. It was my turn.
“Never confuse movement with action,” I solemnly said. It didn’t get the same quick reception as the others; however, slowly, the group began to nod in unmistakeable agreement.
“Yes,” exclaimed Lin, “that is brilliant! Where did you hear that gem of Scrum advice?”
I looked around the circle of my peers and with a smile said, “Ernest Hemingway.”
Putting aside the source of this counsel, including the fact that it was never intended for Scrum and that the person who penned it never even used a computer, I have yet to come across more sound advice. That is because confusing movement with action is the same as confusing output with outcome; two valuable measures in the Agile methodology.
Output can be considered the story of what you produced, such as velocity and volume. However, where output falls short is in addressing the value of what was produced. For that, we have outcome, which is arguably a more appropriate measure for development as it helps to quantify the actual performance and success of the processes we put in place. Sadly, we see Sprint Reports, Burndown, Burnups, and Velocity Charts all relating to output, likely because outcome is harder to interpret. Which begs the question – how do we ensure we work, and more importantly, deliver, on both?
While the four Scrum events admittedly seem to showcase output over outcome, the latter is still present and teeming with value – that is, if you know how to find it. Today, we’ll show you how to do just that by extracting what output should be gathered from each event as well as the often overlooked, but no less valuable, outcome.
Daily Scrum
At the heart of the Agile framework is the Daily Scrum or Daily Standup. These short, 15-minutes meetings are designed to improve communication, with all members arriving prepared, punctual, and ready to answer some variation of the “three questions” we’re all too familiar with.
In the Daily Scrum, the output can be considered:
- Looking for anything that is stopping the team’s current effort and reporting these impediments back to the team
- Once established, it is imperative to devise an action plan to deal and ultimately remove these impediments
- What stories are completed and what will the team be working on that day
The outcome, on the other hand, should be:
- An updated sprint backlog. This should be done by keeping it in front of you during the Daily Scrum, so you can determine how impediments will affect it and adjust accordingly
- Improvised plan to meet the sprint goal that is based on the team’s updates
It is imperative that each sprint has a sprint goal that can act as a catalyst for inspiration and instil a sense of achievement in the team. When trying to achieve value and not just velocity, you’ll likely find that teams function better and work with an increased sense of collaboration.
Sprint Planning
The Sprint Planning event is one that focuses on two main questions:
- What needs to be and can be delivered in the Sprint?
- How will the work needed for the execution of the Sprint be achieved?
Answers to the above are derived from the Product Backlog, past product increments, projected capacity, and past performance. However, when dealing with output and outcome, it is usually the Product Backlog that yields that most information in the Sprint Planning phase.
The output from Product Backlog includes:
- A shared understanding of the items to be taken into the next Sprint
- Ensure that definition of ready is met for all the stories
Concerning outcome, the Product Backlog yields:
- That stories in the Sprint are fully understood by the team, increasing the probability of achieving true value
- The team becomes clear on the value and acceptance criteria of the stories, including the rationale behind it
- The team clearly defines ask and have prerequisites ready to estimate the story, sorting out all assumptions before development
- Items are more refined and prioritized based on customer impact and business justification
By the end of the Sprint Planning, the team should be able to explicitly state the desired outputs and outcomes to the Product Owner and Scrum Master, as well as how they intend to accomplish them in the upcoming increment.
Sprint Review
During everybody’s favourite Sprint Review, the efforts of the team are assessed against the sprint goal. The team will showcase what they have accomplished; however, this shouldn’t be limited to merely output.
Typically, a Sprint Review takes the form of a demo, with the team ideally having completed each Product Backlog item. Generally speaking, the success of these meetings is based on the simple output of:
- The Product Owner reviews and accepts the delivered product increment or provides feedback
Seems a little sparse if you ask me, but when you dive into the outcome of the session, you start to see some real value brought to light. These outcomes include:
- A strengthened partnership between stakeholders and the development team. The focus should be on the experience, not the demo
- Feedback on the increment produced in the sprint with a particular emphasis on the stakeholder’s needs in the backlog and how the feedback will be incorporated into the stories
- A team-wide agreement on changes to scope based on feedback, along with the timeline of the planned release, with a focus on how it will impact the vision of the project
At the end of the Sprint Review, not only should the team have a revised Product Backlog that helps define the next sprint, but it should also act to clarify that valued outcomes are on par with output.
Sprint Retrospective
Often the most misunderstood of all Scrum events is the Sprint Retrospective. This is designed to afford teams the opportunity to inspect themselves and create a plan of action for improvements moving into the next Sprint. It is also an excellent opportunity to review and assess output and outcomes.
The output from the Sprint Retrospective include:
- What issues arose in the last sprint
- Develop an action plan to fix them
- Develop a proactive approach to prevent them from happening
The most important and yet, usually overlooked outcome of this event is one that can be found in a core Agile principle – to at regular intervals, reflect on how to become more effective, and then fine-tune and change behaviour accordingly. In other words, Continuous Improvement. This includes looking for technical debts to upgrade the code base and working with Product Owners to clean and maintain the Backlog.
If asked what sounds more compelling, a company that increased its velocity by 300% or increased its share price by 30%, the answer is obvious – 300%. However, this point beautifully illustrates the importance of asking the right question, because while 300% is more compelling, an increase in 30% share price is by far more valuable. When working in Scrum, it is essential to ask the right questions to not only get a more accurate picture of the development but to determine if you are confusing “movement with action.”
