Focus on Outcome

Think of a product you use—one you’d tell others about. What makes that product good, great even? I’m pretty sure you’ll say things like it’s easy to use, it solves a problem, it’s fun to use, or it makes money. Notice how the things you thought of are the benefits to you as a customer of the product, or maybe even the financial benefits to the company that funded the product.

Notice how you didn’t think delivered on time or delivered under budget or created happy stakeholders. That’s because those aren’t product success factors; they’re project success factors.

Being more product-centric means you’ll need to focus on and measure what your customers and users do after you deliver them what you built. We hope they see it, try it, really use it, keep using it, and hopefully say good things about it. Those are the outcomes because they are what happens after you release. And if customers and users do those things, that usually results in some impact for the organization that paid for the product to be built—for example, return on investment, increases in market share, or cost savings for things built for internal use.

Bad Scrum Focuses on Output

Well-intentioned people using Scrum can easily lose sight of outcome and impact. It’s easy just to focus on the output in Scrum. We start each Sprint by predicting how much potentially releasable software we can build. We fix the time to the length of a Sprint. We fix the cost to the number of team members on our team. And then, we ask the team itself to fix scope by promising what they will deliver in the Sprint. We talk every day about the progress of building that stuff. At the end of every Sprint, we review what was built, argue about whether it’s really “done-done,” discuss if our velocity was what we expected, and maybe even get feedback from our stakeholders, who usually aren’t the people actually using the software.

It’s odd that the things that matter most to product success aren’t the things we spend time worrying about. So, you’ll need to fix that.

Keep Effort and Outcome Visible

You might have noticed that it often takes several Product Backlog items to produce a feature or capability you can actually release. It’s those actually releasable chunks we can measure outcomes on. So, every time you release a chunk that users can use, stop and celebrate that. Discuss how long it actually took. Did it take days? Weeks? Months? Quarters? Build a simple visualization that organizes them left to right by actual effort. Tag the features that took longer than expected and discuss why.

Now the hard part. You’ll need to wait for users to actually see, try, use, and keep using that feature or capability. Because if they don’t, I promise you won’t get the business impact you’d hoped for from building it. Make your visualization two-dimensional by adding an actual outcome axis. Items start in “don’t know” because you won’t after you first ship them. The buckets after that are “awful,” “OK,” and “awesome.” Make it a continuum. You’ll end up with something that looks like this:

Every Sprint Review, discuss those features you shipped in prior Sprints and what you know so far about their outcomes. Discuss whether you could or should make improvements to those features to improve outcomes. Really celebrate awesome outcomes, because that’s where the value really comes from.