After weeks or months of hard work, the new website order module is finally live. Now, of course, you hope that your visitors use your newest addition right away. But even though you've put a lot of time and effort into its development, you see no effect. Visitors are gone again right away. How come it doesn't work? Fortunately, there is a solution to this: make sure you have a feedback loop in every sprint.

In this article, I describe 2 ways to ensure that each sprint is a feedback loop for new initiatives, so that teams get to work in a more informed way. Here, 2 principles are essential, namely, Outcome over Output and Jobs to be Done.

Outcome over output

This concept was introduced in 2019 by Josh Seiden. Josh, in his eponymous book the following about Outcome over Ouput:

”In the old days, when we made physical products, setting project goals wasn't that hard. But in today's service- and software-driven world, “done” is less obvious. When is Amazon done? When is Google done? Or Facebook? In reality, services powered by digital systems are never done. So then how do we give teams a goal that they can work on?Mostly, we simply ask teams to build features-but features are the wrong way to go. We often build features that create no value. Instead, we need to give teams an outcome to achieve. Using outcomes creates focus and alignment. It eliminates needless work. And it puts the customer at the center of everything you do. Setting goals as outcomes sounds simple, but it can be hard to do in practice.

A further explanation can also be found in this webinar by Josh Seiden from 2020.

In short, put your visitor at the center of everything you do. You do this by building results that match visitors' desires. But how do you know what desires visitors have?
You can identify the needs and problems of website visitors by usability testing, design sprints, “double diamonds” and experiment. Here it is important to start from your visitors ’Jobs To be Done.

Jobs to be done

You may have heard of this principle, but Jobs To Be Done is, in a nutshell, the answer to the question: What does your visitor hope to achieve when they purchase your product or service?

“After decades of watching great companies fail, we've come to the conclusion that the focus on correlation-and on knowing more and more about customers-is taking firms in the wrong direction. What they really need to home in on is the progress that the customer is trying to make in a given circumstance-what the customer hopes to accomplish. This is what we've come to call the job to be done” - “Know Your Customers’ “Jobs to Be Done”" by Harvard Business Review

In practice, we see that these principles of knowing your customer are often disconnected from the agile/scrum process. This is a shame, because then things are built without a feedback loop from the end user. With the result that you will be surprised when your hard work has not had the expected effect. As promised, in this article I'll give you two options you can use to turn every sprint into a feedback run. Where I write about experiments you can also read studies, or vice versa.

Option 1: A percentage number of experiments or studies per sprint

There are organizations that have agreed on the percentage of experiments per sprint. It is then important that everyone on the team is actively working on the objective. Management directs the scrum team with possibly a CRO specialist in their goals and personal plans among themselves. When the customization goes live, it is monitored and analyzed. The results are taken into account in defining the customizations and features on the backlog.

Examples:
Target: # experiments per sprint.
Goal: 25% of the backlog is an experiment.

Pitfall: impatience
There is an important ‘but. Monitoring and analysis often takes 1 to 4-5 weeks before the outcomes are clear. In practice, impatience is often one of the biggest pitfalls in an effective sprint. By discussing a few experiments per sprint, a lot can still go live without looking at the effects. In addition, it often happens that the tests are relatively small (copy/color tests) because the sprint is already fully scheduled.

Option 2: The discovery and delivery process align.

An awful lot has been written about finding out customer needs through underlying steps and research in a Discovery Sprint. Just Google Discovery Sprints. In addition, an awful lot has been written about scrum work (delivery) and how to apply it in organizations. You don't see a combination of discovery and delivery sprints much, while in practice I see that this is where the friction is. How do you make sure that building features and new concepts is not separate from figuring them out with the help of customer feedback? How do you monitor what you put live and how do you take those results into the “front end” thinking out your products? How do you make sure that as much as possible of what goes live has been tested and know what effect it has? The following three steps will help you.

Step 1: Keep experimenting with your scrum team.
Learn what does/doesn't work on your current platforms and incorporate these insights into your new concept. If you don't have any existing platforms, skip this step.

Step 2: Think carefully about your team composition to blend the two sprints together.
In addition to the development and scrum team, you also work with a second team that includes a product owner, conversion specialist, psychologist, designer and possibly a data analyst or coordinates the product team in the feedback from users and towards the development team. These team members gather the insights about customers or their “Job To be Done.”.

Step 3: Get into the rhythm of the sprint.
Organize a discovery session every week in which you combine the outcomes of surveys. In this session, work the outcomes into designs or backlog items that can be picked up.

And voila: that's how you create a continuous feedback loop!

Lean UX within an Agile environment, by Dave Landis

Finally, additions, ideas and DiDo#40

I'm sure there will be many more ways to become more and more grounded. I'd love to hear from you if there are any additions or ideas! And: we are hosting another  DiDo: Results are not Learnings And you can be there too! Sign up using the form on the event page. Will we see you then?