Ir al contenido

Trust system

De Scrum Manager BoK
Esta página es una versión traducida de la página Sistema de confianza. La traducción está completa al 100 %.
⏱ 5 min  ·  📅 2026
The confidence system is a mechanism through which a team declares, during each review of its OKRs, the extent to which it believes it will achieve each key result by the end of the cycle. It does not measure progress made, but rather the expectation of reaching the goal; it transforms the tracking of OKRs into a conversation about decisions, rather than a report on percentages.

Progress and confidence address different questions. The percentage indicates where the team currently stands; confidence indicates whether it believes it will reach its goal. A 60% figure coupled with low confidence is a more valuable warning sign than a 30% figure with high confidence, because it points to exactly where a decision needs to be made.

Origin

In Radical Focus, Christina Wodtke presents this as one of the two components used to manage OKRs throughout the cycle—the other being the final score. She proposes a confidence scale from 1 to 10 for each key result, based on a deliberate convention: a challenging key result starts at 5, representing a 50% probability of achievement. A key result that begins at 8 or 9 was not sufficiently challenging, while one that starts at 2 was likely unrealistic.

The scale is reviewed every Monday during the weekly check-in, and each person reports whether their confidence has increased or decreased since the previous week—and why. The value of the system lies not in the number, but in that explanation.

The two scales in use

Scale How it is expressed Pros and cons
1 to 10 (Wodtke) Each key result is assigned a number; a challenging KR starts at 5. Allows for the detection of small shifts—from 5 to 4—before the risk becomes obvious. Requires discipline to ensure the number doesn’t just become a hollow ritual.
Traffic light (green / amber / red) Each key result is assigned a color. The most common approach used by teams and in various tools. It sacrifices nuance but retains the essentials—provided the color reflects confidence in achieving the goal, rather than the progress made so far.

Confusing the two interpretations is the most common error when using the "traffic light" system: a key result might show as "red" at the 70% mark if the team already knows that the remaining 30% depends on something that is not going to happen.

The assumption as part of the statement

A color or a number without an explanation is not actionable information. What makes the system useful is the underlying assumption—formulated in a way that can be verified: "We are at 'amber' because we are operating on the assumption that the data team will deliver the data flow we need this week; if it doesn't arrive, we move to 'red'."

Stated in this way, the assumption allows for three things that a percentage does not: identifying whom to speak with, determining when it will be known whether the condition is met, and deciding in advance what will be done if it is not met. At its core, the trust-based system serves as a mechanism for the early detection of dependencies and risks.

Why it depends on culture

The system only works where flagging a risk in a timely manner is appreciated rather than penalized. If a "red" status is perceived as a failure, teams learn to keep things "green" until a breach becomes unavoidable—meaning the system stops providing warnings precisely when they are needed most.

That is why its adoption is not a matter of tools, but rather of psychological safety, and why it is still in the process of becoming firmly established: the mechanism itself is simple and well-documented, but the cultural conditions that support it are not universal.

Common errors and anti-patterns

  • Confusing progress with confidence. Marking items as "green" based on what has already been covered—rather than on the likelihood of achieving the intended outcome—strips the system of its substance; it merely duplicates existing percentage data without adding any new insight.
  • Assigning a status color without the underlying rationale. An "amber" status without an explanation is not an alert; it is just noise. No one knows what action to take in response to it.
  • Punishing a "red" status. How management reacts the first time a "red" status appears determines whether the system will continue to function effectively for the remainder of the cycle.

Resources

🏦 OKRs and Product StrategySkill Arena · Scrum Manager

🏦 Agile Product Operating ModelSkill Arena · Scrum Manager

References

See also

Do you want to move forward in agility? You can look for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.