Shift Left: Value Creation in Scrum

As a tactical framework, Scrum is good at delivering Increments into customers’ hands. As we work in iterations, we probably do that several times per month, mitigating risk by closing feedback loops. Nevertheless, there is a potentially hazardous void in the framework that successful Scrum teams start plugging early: how to figure out what is worth building—product discovery—in the first place. As a result, value creation in Scrum is not as straightforward as you might have thought.

The Context of Value Creation According to the Scrum Guide

Let’s start with a look at the manual: “The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.” (Source.)

So, there is an overarching long-term objective that guides the Scrum team. Where does it originate? We don’t know. All we understand is that the “Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.” Also, the “Product Owner is also accountable for effective Product Backlog management, which includes developing and explicitly communicating the Product Goal.” (Source.)

For whatever reason, our Product Owner knows what is most valuable and uses that knowledge—supported by their strong position within the Scrum team and the organization—to guide the Scrum team in the right direction of value creation. Practically, however, Scrum’s approach leaves the whole area of product discovery out of the equation, potentially reducing the return on investment for all stakeholders.

Product Discovery in Scrum—The Big Picture

Garbage in, garbage out. No matter how well your team practices Scrum and how eloquently they create new Increments, the whole effort is in vain if no one considers those valuable. Unfortunately, there are many reasons to end up here, for example:

• Your Product Owner is no Product Owner in the first place but a scribe, taking orders from the owner/founder or those who fund the Scrum team.
• Your Product Owner follows their instincts, and no one on the Scrum team challenges the validity of this decision process.
• Your Product Owner is “data-informed;” however, they picked the wrong metrics leading them astray.
• Your Product Owner invests in user research; however, they manage to select a non-representative target group among your customers.

Any of these scenarios will result in an inferior Product Backlog, resulting in less desirable Increments, questioning the Scrum team’s value creation process.

Therefore, let’s consider a Scrum team’s value creation process as an arch:

We start with the vision and strategy on the left side: how do we want to shape the future, and how can we turn the idea into reality while contributing to the sustainability of our organization?

Operational considerations follow this step: how do we position our Scrum team for success? Here, we would find a product roadmap or Product Goal feeding into the Product Backlog, representing the best use of a Scrum team’s time.

The last step is tactical, comprising the Sprint Backlog, the Sprint or product delivery, and the Increment(s). Here, the Scrum team makes the most significant investment decision.

If you consider the effort—in other words: direct expenses and opportunity costs by allocating the Scrum team’s time—creating an Increment is the most expensive. While you can create a new product vision over a coffee on a napkin, creating an Increment is a real commitment. Therefore, you want to shift as far to the left as possible to figure out what is worth building. 

In other words: product discovery is an essential part of Scrum, although it is not mentioned in the Scrum Guide.

In my experience, there are two critical moments in this value creation process that deserve a Product Owner’s full attention:

1. Getting real with product discovery by applying one of the many techniques created for that purpose: Lean Startup, Lean UX, Design Thinking, Design Sprints, Dual Track Agile, Continuous Product Discovery, etc., to separate the wheat from the chaff.
2. Validation: Once you have identified your candidates for value creation, ensure to validate or falsify your hypotheses by running experiments before feeding them into the Product Backlog.

As you may have guessed, both moments benefit from including stakeholders and team members in the process; value creation in Scrum is a team sport. Think of the Product Owner as a “team manager” or “coach” in that respect. 

Ultimately, you need to establish a system that identifies and validates potentially valuable new Increments, feeding them into the Product Backlog for further consideration.

This system does not require specialized tools but the support of the whole organization and your Scrum teams. Therefore, it will need to be tailored to the requirements of your organization, considering your market and the prevailing constraints, and may take years to establish. So, what are you waiting for?

Conclusion

Value creation in Scrum is more complex than you might have thought. As soon as possible, you must overcome Scrum’s product discovery void to ensure that the Product Backlog represents the best use of a Scrum team’s time at any given moment. Otherwise, your Scrum team may deliver returns below its potential. Therefore, ignore product discovery at your peril. 

How do you handle value creation and product discovery in Scrum? Please share your experience with us via the comments.