Alan O’Callaghan

The job of a Scrum Team is to deliver the highest possible business value to the customers of the product it is building. In the most fundamental terms, this means the Scrum Team is a business unit, not just an implementation/execution group. As a self-organizing team, the Scrum Team as a whole assumes the responsibility of ensuring that all of its decisions are in alignment with business missions and goals.

The Agile community is well aware that the product is “discovered” throughout the development process. At the beginning, there is hopefully a vision, but not the specific details of the final system. These emerge iteratively and incrementally. There seems to be less awareness that this is also true of the business value enshrined in the product. The specifics of business value also emerge iteratively and incrementally as assumptions are either validated or invalidated. The product vision provides a value compass for the Scrum Team. Each of its decisions can be evaluated against that vision, whether it moves the team closer to realizing the vision or takes them further away from it.

It is primarily the Product Owner role, of course, that gives the team the capability of validating its assumptions concerning the value of its work. The Product Owner is charged with maximizing the value of the product and the work performed by the developers. As a full member of the Scrum Team, the Product Owner will collaborate intensively with the Development Team to achieve consensus, but they also—uniquely in the Scrum Team—have the independent authority to make decisions on business issues. The decision process might otherwise time out before full agreement can be reached. It is, however, a poor Product Owner who relies solely on that authority. The best ones understand that the Scrum Team needs to be seduced by a common purpose if it is to be truly self-organizing.

This means putting the question of business value front and center in your Scrum Team. Product Owners need to get answers to three questions from stakeholders: What is the goal? Why is it important? How will you know when it has been achieved? The answers to the first two of those questions reveal why the product is being developed in the first place. Communicating to the rest of the Scrum Team (and, indeed, the wider stakeholder community) what the most important thing is to be worked on next is fundamental. But the Team will be far more effective if it also knows the why behind the items at the top of the Product Backlog. The third question (“How will you know when the goal has been achieved?”) allows the meter by which value can be measured to be discovered.

The answers to these questions are gathered not just at the beginning of a development initiative, but throughout the process. Things change. While the overall goal is likely to remain stable, and the product vision is less volatile than detailed requirements, change is the one constant we can rely on in a complex world. And change can be distracting. The Product Owner who opens every Sprint Planning meeting with a reminder of what the goal and the vision are and where the latest Increment stands in relation to them, as well as pointing to the items currently at the top of the Product Backlog, is much more likely to keep the team focused on business value than one who does not.