Introducing Conditions of Satisfaction to a Team

Last we talked, I was arguing that if estimates are supposed to be accurate, we’d call them actuals. That’s not to say that estimates are meaningless. When used appropriately, they’re valuable and serve an important purpose. Instead, my point was this:

Estimates are about mathematics. Expectations are about human connection. That difference matters.

Speaking of expectations, you should have one of me. I promised I’d finish what I started by sharing how I introduce conditions of satisfaction to a team. To set the context, I encourage you to read my previous post before continuing.

What Do We Need?

Assuming conditions of satisfaction are new to a team, we’ll need a few things:

• A fundamental understanding of the the uses and misuses of conditions of satisfaction.
• A few members of a team willing to experiment with conditions of satisfaction. We’ll talk later about why we don’t need the whole team doing so at the start.
• Some work where these conditions will be beneficial. Something the size of an epic could be useful, but it’s up to the team and the context.
• Access to and buy in from the person accepting the work. Sometimes this is the Product Owner, but I’m sure not all of us are using Scrum.

How Do We Start?

• Set up 30 minutes with yourself, the work accepter, and up to two team members. If more than two members are part of this experiment, set up multiple 30 minute meetings.
• A tool to visualize our upcoming conversation like a white board or virtual canvas.
• An ask to each of our participating team members to bring a non-trivial, story-sized work item. Ideally, work on this item hasn’t yet begun but will in the next few days.

What are Conditions of Satisfaction?

At the meeting, we’ll start by explaining what conditions of satisfaction are. I usually end up explaining it one of a few ways depending on the audience:

• Conditions of satisfaction are to local variables as definition of done are to global variables. Put differently, definition of done applies to everything in the backlog while conditions apply only to this one thing.
• It’s a black box so put aside what’s inside. Instead, think of conditions from the user’s point of view. When we’re done, what behavior has changed? What’s new?
• At the start, we have a set of inputs and outputs. At the end, we have a set of inputs prime and an outputs prime. Those primes are probably our conditions of satisfaction.
• Avoid using conditions to explain what work we’ll do. This isn’t about us but about our users. Again, think black box. Don’t use them to create tasks for ourselves.

How Do We Solidify this Construct?

We begin with a hypothetical and end with the real work:

• Let’s say we’re creating a login system like Mike Cohn talks about here. I ask the room what the conditions of satisfaction could be.
• During the hypothetical, a few things inevitably occur:
  • They create something that falls outside of this small slice like implementing password reset flow or two-factor authentication. Add these to some mythical backlog to the side and talk about how this will be work for future iterations.
  • The group tries to create tasks. Ask them to avoid this. Remind them of the black box. Write it on our board and strike it out.
  • They create actual conditions of satisfaction. Write them down and emphasize how making the implicit explicit made our short-term goals more clear.
• After answering questions and ensuring the group appreciates the fundamentals, do the same exercise for the work items the two team members brought to the meeting. Facilitate the conversation between team member and work accepter in the same way we did for our hypothetical.

What Can Go Wrong?

The conversation we created above is the easy part. As much as possible, we want to answer yes to all these questions to maximize success:

• Are these select team members and the work accepter truly on board with using conditions or was this suggestion imposed on them?
• Is it clear what part of our backlog we’re experimenting with conditions of satisfaction? It may be just the stories the members walked in with or a whole epic. Whatever it is, make it explicit.
• Is it clear who is responsible for and how conditions of satisfaction are added to the work items? The how is up to you and the team. Some like to add them at refinement while others like to do so informally in pairs.
• Are the conditions going to be used to accept the work by the work accepter?
• Will the conditions be used by the team members to decide when the work is complete?
• When a potentially new condition becomes known for a work item, do the team members know what to do?
• Are the team members and work accepter willing to talk about how it did or did not help them at the next retrospective? Assuming it was a good experience, our hope is that the team will continue adopting them.

If you try this technique, let me know how it works for you and the team. Until next time.

---