OOPSI for better collaboration

Small Talk with Jenny Martin (Transcript)

This blog post is the transcription of the chat we had with Jenny Martin about her OOPSI Workshop on 14 January 2025.

The conversation has been slightly edited to better fit the written format. Enjoy!


Avanscoperta: The first Small Talk of the year is an interview about OOPSI with Jenny Martin, the inventor of the technique.
Jenny, let's start with the basics. What is OOPSI and what does it stand for?

Jenny: OOPSI stands for outcomes, outputs, process, scenarios, and inputs.

It's a collaboration framework that helps teams collaboratively break down complex problems. All the different sections of OOPSI offer an opportunity to collaborate, align the team towards value, and get real concrete focus for what you're doing next.

It essentially comes from wrestling with different analysis and testing practices, trying to figure out how to get started, start small, and integrate other practices usefully.

Avanscoperta: Thanks, Jenny, so we covered the basics. One of the things we read on the website description is something like you can just start small and still deliver something valuable, right?

Jenny: OOPSI helps you navigate towards a point where you can get started.
When we work in an agile environment, there are often many small user stories and lots of complexity. It's difficult sometimes to know how to get started, even though you need to collaborate and have these conversations.
It does this by guiding you through these different steps, which spell out OOPSI. As you go through those steps, each layer is an opportunity to prioritise, inspect, illustrate, and achieve a shared understanding.
So you're able to work through those different sections to a point where you have a really concrete example-based test for a specific process, generating some really concrete specific outputs that will help define what you're doing and align the team towards it.

So how does OOPSI work?

In terms of how it fits in with what you're normally doing, you might have a kickoff OOPSI workshop at the beginning of an initiative, and you might figure out the key outcomes and the key outputs and illustrate those, which will give you a really good understanding of the higher level of scope that you're looking at.
You'll then examine those outputs and look for the really important ones that you want to generate first as part of your system.
This will lead you to analyze the process and hunt for the most important scenarios so that you can start developing your user story and different acceptance criteria and tests.
It helps you defer some of that thinking and still have an opportunity for really good feedback as early as possible.

Avanscoperta: One of the things you mentioned is that OOPSI is about the whole team, right? Not only developers or a specific profession, because something is only targeted at some parts of the business or of the IT department.
What we see with OOPSI, as well as with other things like EventStorming, is that it's somehow aimed at the whole team.
Let's be more specific and say, for example, who would be the best person to use OOPSI and attend the workshop?

Jenny: It does change a little bit as you go through. So it's useful to involve, all kind of key stakeholders and key people involved in an initiative at the beginning, particularly for the outcomes and the outputs part where you probably want to involve the customer or somebody as close to the customer as you can, similar to EventStorming, right?
So the domain, you're understanding the domain, you're understanding the ubiquitous language and you're figuring it all out together. For that part of the process, you would typically have somebody representing domain knowledge, somebody representing development or design knowledge, somebody representing testing knowledge or expertise, all different representations.

As you move through OOPSI and into the scenarios and inputs part of it, it looks more like the three amigos, where you'd have a developer, a tester, and a product owner or business analyst figuring that out together.
So OOPSI represents different levels of detail. As you get closer towards the end of OOPSI, you're looking at more low-level details.

Avanscoperta: At each one of these five stages, we might have different people involved.
Jenny, where did it start? Where did the original idea come from?

Jenny: Eight or nine years ago, I was working in a small team, and we were using practices like specification by example, from Gojko Adzic, which is an acceptance test-driven development type of practice, which really brings forward concrete examples into the discussion on the development team to help you avoid mistakes and rework. We were using that with really, really great results.

I was also interested in Chris Matts's work, which examined feature injection and practices based on starting with outcomes and using outcomes and behaviour to drive your approach to software development.
I was also looking at some work by Kent McDonald on agile analysis and how you actually get into those rhythms of agile analysis.

It wasn't just me looking at this on my own, there were other patterns of agile behaviour in teams and other experts who were looking for a bit more structure around processes, in particular how to help collaborate.

Jeff Patton's story mapping was also happening when I first discovered this, and as I was talking about it to my colleague Pete Buckney… it sort of just developed.
I started writing “outputs, outcomes, process, inputs,” and I thought there was a bit in the middle that brought things together, like cucumber and scenario stuff. Then I realized it was “OOPSI.” Of course, that's a bit tongue-in-cheek, but it's kind of stuck since.

Avanscoperta: We're talking about roughly 10-15 years ago, is this correct?

Jenny: We said all of those things when we started using it, and it sort of formulated into OOPSI, I guess, in about 2015, so gosh, yes... that is 10 years ago.

Avanscoperta: Thanks Jenny for the overview. Let's go back a bit to what we are actually gonna do during the workshop. We said it's two half-day modules remote. What's gonna happen?

Jenny: On the first day, we'll examine the key concepts around OOPSI, how you do it, the key process patterns, and some of the principles behind it. The second day is much more about hands-on work through examples of OOPSI so that you can feel confident actually taking it out there into your organization and having a go.

Over the years, I've developed many examples of OOPSI and many exercises, which helps it land because I've been doing this for quite some time in various ways.
It's very much participatory. There's room for discussion and reflection on how this might work in your environment, how it might work based on the software development methodology that you’re using, because you can really apply it to all sorts of environments.

So on the first day, we have an overview and all the key principles, methods and process patterns, and on the second day, it’s much more about working through worked examples, discussing, sharing and leaving feeling comfortable that you've really able to put it into practice.

Avanscoperta: As you mentioned, the workshop will be very participatory and interactive despite being remote. Of course, you won’t just sit and watch slides, and that applies to all our workshops, and yours will be no exception. We can't wait to have this full interactive experience. We'll be on Miro, Zoom, and Slack…

Jenny: It's incredible what you can do with Miro and how you can design remote training to be engaging and powerful. And the post-it notes don't fall off the wall, so there's a benefit there.

Avanscoperta: It’s the first time I've considered this after all these years—that’s a great benefit indeed!
I also know you are in the process of formalizing this wealth of knowledge in a book. As it’s not a secret anymore, would you tell us more about it?

Jenny: As you probably know, in the last few years, I've been involved in lots of different things, including product and agile development stuff. I also work with teams on other things.
And so for that reason, I haven't written about OOPSI for a little while. And then it just keeps coming back to me from time to time.

I keep hearing that somebody went to an interview and was asked what practices they use, and they've answered, “I use OOPSI”, or I find out that the consulting company in the UK has done comparisons with example mapping in OOPSI and has chosen OOPSI, or I find out that organization based in the States somehow found out about OOPSI and they're using it to underpin their development framework and testing framework.

This has given me a real nudge this year, as it keeps coming back, to actually write something down beyond the articles and blogs that I've done. So I’ve been accumulating content, examples and all of that stuff for quite some time, and now it's just about getting on and doing it.
I'm actually doing it in the open with a colleague who's also writing a book and we're doing fortnightly sessions, zoom calls, and asking each other questions, and sort of capturing all of our thoughts verbally and then going back and refining them.
So far I've already done the introduction and the overview.

Avanscoperta: The feedback and writing process with your colleague, where you literally verbalize and write down as you speak, is just amazing.

Jenny: Also there’s a lot of folks in the community, people with a lot of agile experience, agile coaching and product development experience. So I'm seeing if I can convince them to rally around and give me some feedback. So, watch this space!

Avanscoperta: Do you already have a release date in mind, or a deadline you gave to yourself?

Jenny: We gave ourselves six months, and we started in December, so that will be June 2025. It feels good.

Avanscoperta: Thanks, Jenny. Now we get to one of the questions we need to ask, and it is the famous, “So what?” After years of talking to experts, at one point in this conversation, you might find yourself asking, “Okay, so what is actually the problem that we are trying to solve?” So I would like to know the same about OOPSI.

Jenny: There are quite a few things actually.

There's wanting to get started small, but not knowing how to break things down, and that's a big one. One of the challenges with agile delivery is knowing when to do the deep thinking and where that fits into your iterations because sometimes it feels like there's no time for that. So it definitely addresses that.

The other thing is about rework. So if you're finding that your team is working on stories or working on implementation and they feel like there's a lot of rework or a lot of errors or that the documentation doesn't feel quite clear enough and there's back-and-forth, OOPSI really helps with that because the practices of collaborating together around examples and making things really concrete are absolutely embedded in the OOPSI approach.

It also gives you a line of sight from the small things you're working on to the bigger picture, which is really important. So, one of the challenges working with small tokens, like user stories, is that teams can feel a bit lost in terms of how what they're working on contributes to the overall problem that they're trying to solve.

So OOPSI takes you through a process where you know how what you're working on contributes to the outcome you're trying to achieve. That's really useful because teams that are strongly aligned towards outcomes make good decisions. They're more motivated because they're solving problems together rather than just being given a load of work over the fence.

As we can see, OOPSI solves lots of problems. It helps you stay aligned with valuable stuff and do the work on the things that are most important first so that you're always working on the most important thing which ultimately helps you optimize your whole process for feedback.

Avanscoperta: The next question is how to get started with OOPSI.

Jenny: The most recent blog that I've done on LinkedIn is the main source as of now.
Understanding the value of collaboration and the use of examples is important. So you might start by just getting together and talking about these things, such as, “what are the outcomes? Tell me about the important outcomes. What are the important outputs that drive those outcomes? Which process do we use to generate those concrete outputs? What are the most important scenarios?”.

So I guess even if you don't know much about OOPSI, it's a good conversation framework. If you find yourself holding the pen, trying to figure out what the needs are of a customer or how to get started, those questions around understanding all those different things will help you get started and help you collaborate around the important stuff and find the gaps.

Avanscoperta: We have a comment from Martyn. “I started using OOPSI on project design to bring out the end goal and drill down from the outcomes into the fine-grained individual work items, even when the outcomes are subjective, looking at outcomes, efficiency, effectiveness, economy, and evidence of empathy.”

Jenny: That’s all it is, really. Starting with the outcomes should always make sense. And then the next step will be exploring how well those outcomes are understood.

One of the pitfalls of user stories is just blindly following some user story kind of parlance without anybody properly understanding or taking the time to understand the problems that they're trying to solve. That's an important one.

Avanscoperta: Let's close with the feedback on OOPSI so far. So, best and worst response to OOPSI.

Jenny: The really good feedback comes from folks who say to me, “This is exactly what I've needed. This has given me clarity and structure in what we're trying to do. It's helped us collaborate. It's so simple”. Or, “Wow, you can get started that quickly with an example. This makes so much sense that everyone can see what they're doing”.

I guess the worst sort of feedback is when people say, “Oh that sounds like a mistake, OOPSI”, and I'm kind of like, “Yeah, you know, it's just an acronym that people know and that they can remember”.

I'm not sure if this is good or bad but when I presented this at Skills Matter about eight years ago when I was doing one of my first talks, somebody in the audience said “Well, if you work the wrong way up through OOPSI, and you start with the inputs, it IS POO”... which is true! If you do it wrong it doesn't work!

I don't know if that's a good thing or a bad thing. It's a nice story, though.

Avanscoperta: Thanks Jenny and see you at the workshop!

Check out Small Talk on YouTube or Spotify.

Credits: Photo by Zdeněk Macháček on Unsplash.


Learn with Jenny Martin

Jenny is the trainer of the OOPSI Training Course (online and in live-streaming).

Check out the full list of our upcoming training courses: Avanscoperta Workshops.

Subscribe to our Newsletter 📩 (available in Italian and English) and be the first to know when we schedule a new workshop or we publish a new workshop.

Jenny Martin

Jenny is an independent trainer and facilitator in collaborative agile and product development techniques and behaviours of high-performing teams.

Enrico Meloni

Event manager and specialist, producer, customer experience, trainers' roadie and assistant - ensuring all stakeholders have a great time and an impactful learning experience.

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.