This is the second article, exploring the Sprint Review event. We look at a practical but fictitious scenario to see what is potentially wrong and what we can learn from it. The reason for the sprint review according to the Scrum Guide, is to inspect the Increment and adapt the Product Backlog if needed. Everyone invited to the sprint review needs to collaborate on the increment and what to do next to optimise value. It is important to get the feedback, but the Product Owner has the final say on the order of the Product Backlog.
Scenario: Monday, 15:02
The afternoon sun is brightening the modern chrome finishes of the big management boardroom. The senior managers love to have meetings here. It is on the top floor right next to the CEO’s office. The whole room seems to exude confidence and power. As the Scrum Team demonstrates the new functionality, a senior stakeholder, John gets up and says: “Guys, I need you to add the integration to the ERP system right away”. The Product Owner steps forward and thanks John for his feedback and explains that the product does not need to have ERP integration at this time and that it is not part of the MVP. Jackie from accounting, adds to the conversation: “John is right, we need ERP integration. We need it now.” You know when you are walking on thin ice and the product owner knows it too. “Sure, John, we will add that to the Product Backlog.” Not many in the room notice the glances between the development team.
Unlike in the previous article, there is good feedback coming from the stakeholders, but it may be interpreted as demands rather than feedback. Some stakeholders will be very senior people with much power and authority and could quite easily sling others along in their demands. Openly displaying support for the big cheese could have good career prospects for Jackie, but it could have a detrimental impact on the product. A good Product Owner takes responsibility for optimising value. A great Product Owner does that in collaboration with all the stakeholders. But not being bullied into accepting a new feature, could be challenging. How do you do that? Bring in the F-Word. “Facilitation”.
Good facilitation can be your greatest ally to get engagement and collaboration, and also levels the playing field. Powerful people can quickly dominate a session and dictate the outcome. By designing activities where everyone participates and using filtering techniques (like dot voting) to reach mutual consensus, the voice of the team is heard instead of one individual. In this example, perhaps adding ERP integration is the right thing to do, but all voices and opinions need to be heard. The Product Owner knows about the minimum viable product (MVP) decisions and the development team clearly knows more than they are willing to share. Only by getting every voice out there, a good decision can be made to ensure they focus on value for the customer. An essential part of great facilitation is to have a working agreement. It is an agreement created by all in the room, preferably in the early days of the project. When the agreement is violated, the team can and should hold each other accountable.
Another area of concern may be with the authority given to the Product Owner in the organisation. The Product Owner has the final say on the order of the Product Backlog and he/she takes responsibility for it. If the authority is lacking or unclear, a good old-fashioned conversation would be required. It is important that the Product Owner and the whole Scrum team understands the role and authority prescribed by the Scrum framework. It is just as important that HR and the Organisational leadership also understands the reasons why it is important. Getting agreement and communicating the role and responsibilities and associated authority, could be a good outcome from the session. An Agile coach or the Scrum master will have a key role to play in this session and the facilitation thereof.
In my own endeavors to be helpful and kind, I have found myself many times before, in a predicament. Saying yes when I should have said no, mostly comes back to bite you. Adding items to the backlog to please others can lead to an overwhelming and unmanageable Product Backlog. I have heard of Product Owners who create secondary lists to manage all the low priority feature requests as an alternative to adding it to the backlog. Unfortunately, by not saying “no”, you are creating an expectation that the feature will be included in the product at some point. Inevitably, you will not get to the low priority items and there will be disappointment later. Knowing when and how to say “no”, is a very important skill to have as a great Product Owner.
Don’t be afraid to say no. Have courage. You will keep the priorities focused on the goal and also improve the relationships with your stakeholders. Be open and respectful. Make it easier for yourself and the team to have great sprint reviews by great facilitation.