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.