As a Product Owner, how do you start your Sprint Planning? Do you craft a Sprint Goal first with the Scrum Team, or do you first define what Product Backlog Items will be part of the Sprint?
I used to start talking about what can be done during the Sprint. I would go through the Product Backlog and agree with the Development Team what to do during the next Sprint. After defining what fits the Sprint, we would do our best to craft the Sprint Goal. Most of the time, we didn’t craft any motivating Sprint Goal. Unfortunately, the results were not encouraging:
- Scope matters: the agreement with the Development Team was done on a feature level. We worried about protecting scope instead of learning. Empiricism was ignored.
- Micro teams: developers had little chance to collaborate. They had a huge pressure to deliver features. Everyone was running in different directions. Imagine a football team where everyone has its own ball. They play their game as they wish. Collaboration evaporates.
- Feature factory: delivering features was our goal. The more we shipped, the better we felt. But if we failed to deliver something, we failed. Our goal was to deliver all tasks of the Sprint.
But why did we do that? When we look at the Scrum Guide (Nov 2017), the Sprint Goal term is mentioned 27 times. However, it’s not clearly stated which comes first, the Sprint Goal, or defining what to do during the Sprint. Well, the room for interpretation can lead to misunderstandings, which will lead to sub-optimal results. Let’s have a look at the Scrum Guide.
What can be done this Sprint?
The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.
— The Scrum Guide, November 2017
Crafting a compelling goal with the entire Scrum Team is the right way to start the Sprint Planning. A successful Sprint Planning will provide the following results:
- Freedom: the Development Team has a compelling goal to achieve. The commitment is to achieve the Sprint Goal instead of delivering a set of features.
- Collaboration: the developers work as a strong team because they have a mission to achieve. They help each other to reach their mission.
- Learning: the Scrum Team embraces change. As the Sprint progresses, the team is constantly inspecting and adapt. The team has no pressure to deliver features. The team aims to achieve the goal the best way possible.
By understanding the purpose and goal of a mission, the people on the ground enjoy the freedom to make decisions in the spirit of the original plan. It promotes teamwork and incorporating new information into battlefield decisions.
At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done”.
— The Scrum Guide, November 2017
When I started my career as a Product Owner, I misinterpreted the increment. If you misunderstand the meaning of it, you will lead the team to a feature factory anti-pattern.
Don’t focus on velocity. Actually, I’d recommend ignoring it. Velocity doesn’t matter. Scrum is not about maximizing the features your team delivers at the end of each Sprint. Scrum is about maximizing the value for end-users and businesses.
Delivering more story points doesn’t mean maximizing the value!
The features delivered are the output. They are a means to an end, never the end itself. As Product Owners, we want to maximize the outcome. In other words, the result of the features. Once we plan a feature, we need to know the outcome we want to generate. If we don’t know the expected outcome, we shouldn’t build the feature at all. Features without outcome are pointless.
Let me give you an example. Imagine your goal is to acquire new customers. Then, you build a member get member feature, where current customers can recommend the product to their friends in exchange for a reward. The feature is the output, while new customers acquired represent the outcome. If no customers are acquired, the feature is not delivering on its expectation. It should be reworked until it delivers or is removed from the product.
Stop optimizing for the amount of effort your development team spends. Start optimizing for the impact the feature makes on your customers. Delivering value is messy. Delivering value requires experimentation, trial and error, and room for reflection. By pushing your team to optimize the delivery of features, you kill the innovation and learning necessary to create a product that matters to your customers.
“The Product Owner may represent the desires of a committee in the Product Backlog “— The Scrum Guide, November 2017
Be very careful how you interpret this sentence. Please don’t fall into the trap I’ve fallen multiple times. Don’t focus on pleasing all of your stakeholders.
When I started my career as a Product Owner, I was not empowered to make the decisions I wanted. I had to align with a committee; then, we could define the direction. I tried to please everyone, that was the biggest problem. By trying to please everyone, we could not match anyone’s expectations. We pleased no one.
“There’s always more to build than we have time or resources to build — always.”
― Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product
As a Product Owner, you should be bold. You have to go into conflicts to clarify what problems worth solving and what don’t. Stakeholders’ wishes will always be more than the Scrum Team has the capacity to deliver. Therefore, it’s your responsibility to understand what worths invest your efforts into.
Until Product Owners master the art of saying “no,” the Scrum Team will be locked in a prison called feature factory. We will build useless features while missing the chance of maximizing the value for the end-user and business.
No worries, you have a way out of the feature factory anti-pattern. You can define a compelling Product Vision, which will allow you to have meaningful discussions about priority.
Without a vision to pursue, everything is arguably a priority.