Challenge Assumptions to Build Trust and Enrich Outcomes

A scrum team decomposes an epic during their backlog refinement meeting. The epic defines a new feature and stipulates backward compatibility with the previous four versions of the product. A team member questions whether their automated testing framework supports the oldest product version that the epic specifies. Based on the question, another team member suggests they’ll need to pull the code for the oldest version and recompile it to support the testing framework. Based on the suggestion, the team decides to size the epic at 13 points, which is large, and informs their product owner that taking the epic into the next program increment will require deprioritizing other epics.?

This sequence of questions, suggestions and the conclusion makes logical sense since it leverages the team’s collective wisdom. But it also illustrates the danger of operating under assumptions. Let’s look at other possible outcomes the team could reach by altering the sequence of events.

Alternative 1

A team member questions whether their automated testing framework supports the oldest product version, based on the assumption that it was released over a year ago. Another team member queries the product database and determines the release occurred only 7 months ago and therefore the testing framework does support it. Based on the validated release date, the team no longer needs to recompile the shipped product and can commit to the epic without delaying other epics.

Alternative 2

A team member questions whether their testing framework supports the oldest product version. Another team member queries the database and determines the product was released over a year ago and therefore is not supported by the testing framework. Based on the new information, the team concludes that supporting the oldest version will cost significantly more than the other three versions that the epic specifies. They ask their product owner if it’s worth the incremental cost. The product owner pulls the usage data for the oldest version and determines it’s significantly lower than the usage for the other three versions. The product owner agrees to drop the oldest version as a requirement. The team concludes they can commit to the epic without delaying other epics.

Assumption vs. Fact

The differences in these scenarios, and the conclusions the team reaches, highlight the value of questioning assumptions. The following diagram illustrates the decisions the team made at each step and the unstated assumption that motivated the decision.

If the team chooses not to question the release date of the oldest product, then the team proceeds to the next logical step—the product is likely incompatible with the testing framework. If team members don’t question the relative value of delivering compatibility with each of the four shipped versions, they may expend effort on a work item that has a lower ROI relative to other backlog items.?

Once a team has progressed through a series of decision points, momentum picks up and a form of sunk cost fallacy sets in: “Now that we’ve navigated a decision tree, we’re reluctant to re-assess an earlier branch in the tree if it was based on an incorrect assumption.” Therefore, it’s imperative to assess the inputs and outputs of each step before proceeding.?

Inspect and Adapt

Scrum is an empirical methodology and therefore it encourages us to inspect and adapt at regular intervals to learn from data and to evolve our process. These feedback loops occur at a macro level, during sprint and program increment retrospectives, but they should also occur at the micro level during our daily interactions.?

A mature team continually questions what they can validate as fact, based on reliable data, and what remains an assumption. If the team characterizes an assertion as an assumption, they can determine the level of effort required to prove or disprove it. Given that we operate within complex systems, it’s often not possible to validate all details. The team can decide to proceed with caution through the remainder of a decision tree given they have identified their assumptions. The team may find it helpful to diagram the discussion in a whiteboarding application, similar to the above illustration, and to label the branches as “assumptions” or “facts.” Team members can take action items to validate the assumptions before making the final decision.?

Trust but Verify

All teams are susceptible to a form of anchoring, in which the opinion of the team member with the most experience, highest title, or loudest voice carries more weight than other team members. While the team should tap the wisdom of subject matter experts (SMEs), they should not fall victim to the fallacy that any team member is infallible. Within a mature team, any member can ask the following questions of any other member:

• What data supports that assertion?
• Can we identify a precedent in which a similar decision succeeded or failed?
• How much effort would we need to expend to increase our clarity and confidence?

In a professional setting, we’re often reluctant to ask questions for which we don’t already know the answers. In the context of validating assumptions, exercising the courage to ask these “na?ve” questions increases the level of engagement and leads the team to a richer outcome.?

Question the Assumptions Not the People

To be clear, I’m not advocating a competition among team members. In teams with insufficient trust and lack of alignment toward a goal, questioning assumptions can devolve into team members continually undermining one another:?

“You’re trying to pass off an assumption as a fact.”

“Why don’t you come up with a better suggestion?”

“I have extensive experience in this area, you should trust my judgement.”

We seek to raise the level of engagement and trust and to reach the best outcome with the least effort. We question the assumptions and conclusions on which they’re based, not the people making the assumptions. We assume that everyone operates with the team’s best interest at heart, everyone is fallible, and the collective wisdom surpasses an individual’s knowledge. A team’s ability to pose these questions without trepidation and to entertain the questions without resentment, demonstrates their maturity.?

Question Our Own Assumptions

We’ve discussed team members challenging each other’s assumptions, or the assumptions made by the person by the author of the story or epic. The practice also applies to each team member as they introspect on the assumptions they have formulated internally about themselves, their role, and the value of contributions from their teammates. Without this introspection, it’s possible for the practice to devolve into the worldview that, “my views are facts and everyone else’s are assumptions.” We should tap our professional and personal experience to contribute to our teams while asking ourselves the following questions to guard against overconfidence:

• Do I understand my motivation for seeking an outcome or recommending a course of action and have I voiced my motivation to my team?
• Do I understand my teammate’s motivations and have I validated my assumptions by soliciting their input?
• Do I have clarity on my team’s objective and am I acting to help my team achieve the objective?
• Do I understand the customer’s needs and acceptance criteria or do I have line-of-sight to the customer or access to the customer via a proxy?

During your next team ceremony, listen for assumptions and request supporting data, when appropriate. If team members are not used to being questioned in this manner, preface your questions by stating you want to ensure the discussion proceeds on stable ground. It’s not your intention to undermine your teammate’s knowledge or authority. Use a physical or electronic white board to diagram the team’s journey through the discussion, highlighting facts and assumptions. If you’re facilitating the discussion, you’re in an opportune role to raise these questions and to coach others on the practice, even if you are not an SME.