Find the work behind the symptom
Inspect the signal, affected workflow, and root-cause context. Start with unreviewed pull requests or a recurring review bottleneck.
Delivery Symptoms
Find the workflow signals behind delivery friction
Investigate unreviewed pull requests, review delays, delivery bottlenecks, and quality risks. Bring the symptom, its severity, and the supporting context into the team review.
Symptoms
Development, review, delivery, and qualityDevelopment, review, delivery, and quality symptoms
Investigate the signals behind delivery friction
Unreviewed PRs
Critical14 merged PRs without review
Why is this a symptom?
Pull requests are merged without a completed code review, reducing independent checks before changes reach production.
Possible causes
Missing review requirements, bypassed branch rules, and urgent changes can allow pull requests to merge without reviewer approval.
Improvement areas
Require at least one reviewer for protected branches, review bypass exceptions, and track review coverage before merging.
Select a symptom and switch between its overview and root-cause context.
From signals to decisions
Turn the signal into a focused investigation
Inspect the pattern, check the context, and follow up with the team responsible for the work.
Use relevant thresholds
Configure thresholds for your engineering expectations and team context. Keep the definitions visible when reviewing active symptoms.
Follow the improvement
Agree on a next step with the team, then revisit the symptom and delivery trend after the change.
What to look at
Review friction across the engineering workflow
Bring development, review, delivery, and quality into the same conversation when a pattern needs investigation.
- Unreviewed PRs and review bottlenecks
- Development flow and planning context
- Delivery delays and production outcomes
- Technical debt and quality findings
- Code review
- Start with unreviewed pull requests, long review times, oversized changes, and bottlenecks in review participation.
- Development
- Inspect development time, work in progress, planning friction, and workflow imbalance with the team’s responsibilities in mind.
- Delivery
- Review lead time, waiting for deployment, release friction, and change failure patterns in production context.
- Quality
- Follow technical debt, recurring quality findings, and related rework to understand where risk is accumulating.
What to look at
Keep the next action connected to the symptom
Use the finding to guide a team discussion and check whether the subsequent workflow change helps.
- Severity and active signal
- Configured thresholds
- Overview and root-cause context
- Follow-up in delivery and quality trends
- Choose the symptom to investigate
- Review severity and the affected workflow. Start with the active signals that are most relevant to the team’s delivery priorities.
- Inspect the overview and root-cause context
- Read the symptom detail and underlying pattern. Check the configured threshold and related review, delivery, or quality evidence.
- Agree on a change and revisit the trend
- Discuss the next step with the responsible team. Follow up on the symptom together with the delivery or quality outcome it relates to.
Common questions
Delivery Symptoms questions
Need to discuss your team or technical setup? Contact us.
What are Oobeya Delivery Symptoms?
Symptoms highlight recurring patterns across development, review, delivery, and quality. Use the signals to locate workflow friction and focus an engineering investigation.
Can we investigate unreviewed pull requests?
Yes. The review view includes unreviewed pull requests and related code-review symptoms. Inspect the symptom detail and review context to understand where work needs attention.
Can symptom thresholds be configured?
Yes. Oobeya supports configurable thresholds so organizations can review symptom logic in the context of their teams and engineering expectations.
How do Symptoms relate to DORA metrics?
DORA metrics describe delivery outcomes. Symptoms provide workflow and quality context that can help investigate the patterns around a change in delivery performance.
What is the root-cause view used for?
Use it to inspect possible contributors to the observed pattern and guide follow-up. Review the supporting work and team context before concluding what caused the issue.
Can we review symptoms across the organization?
Oobeya supports symptom visibility at team, manager, and organization levels so recurring issues and concentrations can be reviewed in context.
Which systems provide the underlying signals?
Symptoms uses connected engineering data from work tracking, source control, CI/CD, quality, and related SDLC systems. Available signals depend on the integrations and data scope.
See Oobeya in practice
Bring the recurring blocker into focus
Walk through review, delivery, and quality symptoms with your workflow, team structure, and engineering priorities in mind.