Part 009 — Requirement, Design, Test, Environment, and Dependency Readiness

Positioning

Definition of Ready bukan commitment resmi dalam Scrum Guide.

Ia adalah complementary practice yang dapat membantu team menilai apakah sebuah Product Backlog Item cukup dipahami untuk dipilih ke dalam Sprint.

Masalah muncul ketika readiness berubah menjadi:

• checklist birokratis;
• approval gate;
• alasan menunda learning;
• atau ilusi bahwa seluruh uncertainty harus dihilangkan sebelum Sprint.

Core thesis: readiness bukan kepastian sempurna. Readiness adalah bukti bahwa uncertainty yang tersisa dapat dikelola di dalam Sprint tanpa menciptakan risiko yang tidak masuk akal terhadap Sprint Goal.

1. Why Readiness Matters

Work item yang terlalu dini masuk Sprint dapat menghasilkan:

• scope discovery besar;
• dependency surprise;
• environment blocker;
• rework;
• carry-over;
• dan conflict antara product dan engineering.

Readiness membantu team membedakan:

Unknown that can be learned during delivery
versus
Unknown that makes the forecast irresponsible.

2. Definition of Ready Is Not Scrum Law

Scrum secara formal memiliki:

• Product Goal;
• Sprint Goal;
• Definition of Done;
• dan empirical events.

Definition of Ready tidak diwajibkan.

Team dapat menggunakan:

• explicit DoR;
• readiness heuristic;
• lightweight checklist;
• atau discussion-based judgment.

Yang penting adalah kualitas keputusan, bukan nama praktiknya.

3. Ready versus Refined

Refined

Item telah melalui aktivitas clarification dan decomposition.

Ready

Team menilai item memiliki cukup clarity dan evidence untuk dipertimbangkan dalam Sprint.

Sebuah item dapat sudah dibahas tetapi belum ready karena:

• dependency belum tersedia;
• test data tidak ada;
• decision owner belum memutuskan;
• atau scope masih terlalu besar.

4. Ready versus Certain

Ready tidak berarti:

• semua detail desain final;
• semua edge case diketahui;
• tidak ada perubahan;
• atau estimate pasti benar.

Ready berarti:

• outcome dipahami;
• uncertainty material terlihat;
• dan team memiliki cara untuk belajar tanpa membahayakan goal.

5. Readiness Dimensions

A practical readiness model may include:

1. Product and outcome readiness.
2. Domain readiness.
3. Scope readiness.
4. Acceptance readiness.
5. Design readiness.
6. Test readiness.
7. Data readiness.
8. Environment readiness.
9. Dependency readiness.
10. Security and compliance readiness.
11. Operational readiness assumptions.
12. Release readiness assumptions.

Tidak semua dimensi memiliki bobot sama untuk setiap item.

6. Product and Outcome Readiness

Questions:

What problem is being solved?
Who benefits?
Why now?
What outcome is expected?
How does it relate to the Product Goal?

Weak item:

Add approval status field.

Stronger item:

Enable support and downstream ordering to distinguish approved, rejected, and pending quotes during the pilot workflow.

7. Domain Readiness

Domain readiness includes:

• terminology;
• business rules;
• state transitions;
• exception behavior;
• and ownership of facts.

Ask:

• Is the rule tenant-specific?
• What happens to existing in-flight records?
• Which state is authoritative?
• What is irreversible?

8. Scope Readiness

Scope should be:

• bounded;
• coherent;
• and small enough for meaningful completion.

Signals of poor scope readiness:

• multiple unrelated actors;
• many business-rule variations;
• several migrations;
• broad “support all customers” wording;
• or unclear exclusions.

9. Out-of-Scope Clarity

Explicit non-goals help prevent discovery from silently expanding commitment.

Example:

Included:
One-level approval for pilot tenant.

Excluded:
Delegation, escalation timeout, multi-region rollout, and migration of existing approvals.

10. Acceptance Readiness

Acceptance should describe:

• expected behavior;
• material negative behavior;
• permissions;
• state changes;
• integration outcome;
• and important quality attributes.

Acceptance does not need every test case, but must support shared understanding.

11. Example Readiness

Concrete examples expose ambiguity.

Example:

Given a quote with a discount above the tenant threshold
When a sales user submits it
Then the quote enters PENDING_APPROVAL
And an approval request is created
And order submission remains unavailable.

12. Design Readiness

Design readiness is proportional to risk.

Low-risk item may need:

• no separate design document.

High-risk item may need:

• boundary decision;
• data ownership;
• compatibility option;
• migration approach;
• and rollout strategy.

13. Design Unknowns

An item may still be ready if design details can be resolved locally.

It may not be ready when unresolved design affects:

• public contract;
• security;
• irreversible data;
• cross-team dependency;
• or release sequencing.

14. Spike Decision

Use a spike when a focused question blocks responsible planning.

A good spike contains:

Question:
Timebox:
Evidence:
Decision:
Remaining uncertainty:

Weak:

Research event architecture.

Strong:

Determine whether the active legacy consumer versions reject unknown approval enum values using replay tests.

15. Test Readiness

Test readiness includes:

• acceptance evidence;
• test level;
• data;
• environment;
• and ownership.

Questions:

• Can behavior be tested deterministically?
• Is a contract test needed?
• Is production-like data required?
• Is the test environment available?
• What failure must be simulated?

16. Test Data Readiness

Test data should be:

• representative;
• safe;
• repeatable;
• and legally permitted.

Common blockers:

• production data access;
• missing tenant configuration;
• stale catalog;
• and impossible edge-case setup.

17. Environment Readiness

Environment readiness is more than “environment exists”.

Evidence may include:

• correct version deployed;
• health checks pass;
• access active;
• dependencies reachable;
• test data loaded;
• and configuration validated.

18. Environment Evidence

A useful status:

Environment:
Integration-2

Evidence:
Health endpoint passing, Quote and Order versions aligned, pilot tenant configured, test data seeded.

Known limitation:
Vendor sandbox rate limit remains low.

19. Dependency Readiness

Dependency readiness should answer:

• What is needed?
• Who provides it?
• When is it needed?
• What evidence proves availability?
• What fallback exists?

A linked ticket is not proof of readiness.

20. Dependency Readiness Levels

Unknown

Need or owner unclear.

Identified

Provider and need known.

Planned

Date and owner exist.

Contracted

Interface or decision agreed.

Available

Input exists.

Validated

Consumer has verified intended use.

Sprint selection should reflect which level is actually required.

21. Access Readiness

Common access needs:

• repository;
• test environment;
• secrets;
• customer tenant;
• observability;
• and support tooling.

“Access requested” is not “access ready”.

22. Data Readiness

For data-dependent work, verify:

• source;
• quality;
• volume;
• ownership;
• privacy;
• and migration/reconciliation.

A schema alone does not guarantee usable data.

23. Security Readiness

Security readiness may require:

• threat understanding;
• authorization model;
• tenant isolation;
• secret handling;
• and specialist review.

Not all work needs formal security approval.

Use risk-based review.

24. Compliance Readiness

When legal or regulatory concerns exist, clarify:

• obligation;
• owner;
• evidence;
• approval lead time;
• and deadline.

Do not discover compliance dependency after implementation.

25. Operational Assumptions

Even before release, refinement should consider:

• observability;
• support diagnosis;
• recovery;
• feature flags;
• and ownership.

The item may not need full runbook before Sprint selection, but material operational risk should be visible.

26. Release Assumptions

Ask:

• Does release need a coordinated window?
• Is customer approval needed?
• Is migration involved?
• Is rollback possible?
• Are consumers version-compatible?

These assumptions affect estimate and sequencing.

27. Risk-Based Readiness

Readiness depth should match risk.

Low-risk example

Internal display copy change.

Medium-risk example

New optional API field.

High-risk example

Tenant authorization, pricing rule, destructive migration, or retry behavior.

Avoid one universal checklist for every item.

28. Readiness as Evidence

Prefer evidence over status.

Weak:

API dependency is ready.

Stronger:

OpenAPI contract is accepted, test endpoint responds, and consumer contract test passes.

29. Ready Decision

A ready decision should be made by the people doing the work with product context.

It should not be:

• unilateral PO declaration;
• architecture approval alone;
• or a project-manager checkbox.

30. Product Owner Contribution

Product Owner helps clarify:

• outcome;
• priority;
• scope;
• stakeholder;
• and business rules.

31. Developer Contribution

Developers assess:

• implementation uncertainty;
• dependency;
• testability;
• integration;
• and operational risk.

32. QA Contribution

QA contributes:

• examples;
• negative scenarios;
• test strategy;
• data;
• and environment concerns.

Quality remains a team responsibility.

33. Architect or Specialist Contribution

Specialist review is useful when:

• risk is high;
• public contracts change;
• security or migration is involved.

Avoid making specialist attendance mandatory for all refinement.

34. Scrum Master Contribution

Scrum Master may help team:

• inspect readiness effectiveness;
• avoid gatekeeping;
• and improve refinement flow.

Scrum Master should not become the “ready approver”.

35. Readiness Checklist Example

## Outcome

- [ ] Problem and expected outcome understood.
- [ ] Product Goal relationship clear.

## Scope

- [ ] Included and excluded scope stated.
- [ ] Item small enough for the target Sprint.

## Behavior

- [ ] Key examples available.
- [ ] Important negative behavior discussed.

## Technical

- [ ] Material design decisions known.
- [ ] Integration and compatibility risks visible.

## Execution

- [ ] Dependency owners and evidence identified.
- [ ] Environment and access are sufficient.
- [ ] Test data and validation approach are feasible.

## Risk

- [ ] Unknowns are manageable.
- [ ] Spike defined where uncertainty blocks commitment.

36. Readiness Scoring Risk

Avoid simplistic numeric readiness scores that create false certainty.

A “9/10 ready” item may still contain one critical blocker.

Use qualitative evidence and critical dimensions.

37. Must-Have versus Contextual Checks

Must-have for most work

• outcome;
• scope;
• acceptance;
• and manageable size.

Contextual

• migration;
• security approval;
• customer data;
• performance test;
• vendor dependency.

38. Ready with Conditions

An item can be ready with explicit condition.

Example:

Ready for Sprint selection if the test tenant is active by Day 2; otherwise switch to contract-only validation and remove rollout scope.

Conditions need:

• trigger;
• fallback;
• and owner.

39. Ready for Discovery versus Ready for Delivery

Ready for discovery

Enough context to investigate.

Ready for delivery

Enough evidence to forecast integrated completion.

Do not confuse a spike with a production slice.

40. Readiness and Story Slicing

Large items often fail readiness because they combine too many unknowns.

Slicing can isolate:

• one rule;
• one tenant;
• one workflow;
• one consumer;
• or one migration cohort.

41. Readiness and Estimate

Poor readiness creates estimate spread.

Estimate disagreement can reveal:

• different scope;
• hidden dependency;
• or architecture assumptions.

Use it as diagnostic evidence.

42. Readiness and Sprint Goal

A not-fully-ready item may still be selected when:

• the Sprint Goal is discovery;
• risk is explicit;
• and outcome is learning.

The issue is not uncertainty itself.

The issue is unacknowledged uncertainty.

43. Readiness and Urgent Work

Incidents and critical bugs may bypass normal refinement.

They still need minimum clarity:

• impact;
• containment;
• owner;
• validation;
• and release risk.

Urgency does not eliminate thinking.

44. Readiness and Technical Debt

A debt item should state:

• current condition;
• recurring cost;
• affected roadmap;
• desired capability;
• and evidence.

“Refactor module” is not sufficiently ready.

45. Readiness and Migration

Migration readiness may require:

• source and target;
• sample;
• mismatch handling;
• validation;
• rollback or containment;
• and decommission criteria.

46. Readiness and API/Event Work

Need:

• contract;
• consumer;
• version;
• compatibility;
• error behavior;
• and rollout.

47. Readiness and Platform Work

Need:

• internal customer;
• problem;
• adoption path;
• service expectation;
• and success signal.

48. Readiness and Research

Research work should still have:

• question;
• timebox;
• evidence;
• decision owner;
• and output.

49. Refinement Horizon

Readiness should be prepared ahead of Sprint Planning, not at the last minute.

Typical look-ahead depends on:

• Sprint length;
• product volatility;
• and dependency lead time.

Internal cadence must be verified.

50. Readiness Aging

An item can become stale.

Changes may invalidate:

• estimate;
• contract;
• environment;
• and business rule.

Re-check items that remain ready for too long.

51. Ready Queue Risk

A very large ready queue creates:

• stale analysis;
• waste;
• and false certainty.

Refine enough for near-term options, not the entire backlog.

52. Readiness Gatekeeping Anti-Pattern

Signs:

• one role approves ready;
• checklist completion matters more than understanding;
• no work starts until every detail is final;
• and items wait for documentation.

53. Bureaucratic DoR

A bureaucratic DoR:

• has many universal fields;
• ignores risk context;
• and prevents learning.

A useful readiness model:

• highlights critical evidence;
• and allows bounded uncertainty.

54. Analysis Paralysis

Symptoms:

• repeated refinement;
• no delivery;
• architecture perfected;
• and uncertainty treated as failure.

Use thin slice or spike.

55. False Readiness

Symptoms:

• green status without evidence;
• dependency ticket linked but unavailable;
• environment assumed;
• and acceptance copied from title.

56. Approval Theater

Multiple approvals can create apparent safety while:

• no one validates integration;
• responsibility diffuses;
• and queue grows.

57. Readiness by Senior Authority

If an item is ready only after a senior says so:

• judgment is centralized;
• team capability stagnates;
• and senior becomes bottleneck.

Use shared heuristics and examples.

58. Senior Engineer Operating Model

Before refinement

• inspect material uncertainty;
• identify hidden boundary;
• and prepare questions.

During refinement

• expose risk;
• propose slices;
• and distinguish local unknowns from blocking unknowns.

At readiness decision

• state evidence;
• confidence;
• condition;
• and fallback.

After Sprint selection

• revisit assumptions when evidence changes.

Guardrail

Do not turn technical expertise into unilateral gatekeeping.

59. Worked Example: Approval Pilot

Candidate item

Support approval workflow.

Not ready because

• actor unclear;
• state model incomplete;
• multi-level scope mixed;
• event consumer unknown;
• test tenant unavailable.

Improved slice

Pilot tenant can submit a quote above threshold for one-level approval, with audit and order submission blocked until approval.

Readiness evidence

• examples agreed;
• event contract additive;
• test tenant scheduled;
• contract test owner identified;
• and delegation excluded.

60. Worked Example: API Field

Change

Add rejection reason.

Readiness questions

• optional or required?
• existing consumers?
• error behavior?
• sensitive information?
• support use?
• rollout?

Evidence

• OpenAPI diff;
• consumer test;
• and example payload.

61. Worked Example: Data Migration

Not ready

Migrate approval data.

Ready enough

• source/target defined;
• 500-record sample analyzed;
• mismatch classes known;
• dry-run report designed;
• pilot cohort selected;
• rollback/containment documented.

62. Worked Example: Flaky CI Improvement

Item

Reduce flaky integration tests.

Readiness

• baseline rerun rate;
• top failure classes;
• ownership;
• target experiment;
• and guardrail that coverage does not decrease materially.

63. Readiness Review Template

## Outcome

## Scope and Non-Goals

## Key Examples

## Material Unknowns

## Dependencies and Evidence

## Environment and Data

## Validation Approach

## Risk and Fallback

## Readiness Decision

Ready / Ready with Condition / Discovery Required / Not Ready.

64. Readiness Decision Matrix

65. Process Smells

• everything marked ready;
• nothing considered ready;
• readiness decided by one person;
• dependencies lack evidence;
• large ready queue;
• recurring planning discovery;
• and spikes have no decision output.

66. Internal Verification Checklist

Practice

• Is Definition of Ready explicit?
• Is it formal, informal, or absent?
• Who participates in readiness decisions?
• Does one role act as gatekeeper?

Evidence

• What proves environment readiness?
• What proves dependency readiness?
• Are test data and access checked?
• Are compatibility tests required?

Risk

• Which changes require design/security review?
• How are spikes represented?
• Can items be ready with conditions?
• How are fallbacks documented?

Flow

• How far ahead is refinement?
• How large is the ready queue?
• Are ready items revalidated?
• What planning surprises recur?

67. Practical Exercises

Exercise 1 — Readiness audit

Evaluate five backlog items across all readiness dimensions.

Exercise 2 — Gate reduction

Take one checklist field and decide whether it is mandatory, contextual, automated, or removable.

Exercise 3 — Ready with conditions

Create a condition, fallback, trigger, and owner.

Exercise 4 — Spike design

Convert a vague research item into a decision-oriented spike.

Exercise 5 — Dependency evidence

Define readiness proof for API, environment, data, customer, and security dependencies.

68. Part Completion Checklist

You are done if you can:

• explain why DoR is optional;
• distinguish ready from certain;
• assess multiple readiness dimensions;
• use evidence instead of status;
• identify when a spike is needed;
• allow bounded uncertainty;
• avoid gatekeeping;
• and create a context-sensitive readiness heuristic.

69. Key Takeaways

1. Definition of Ready is a complementary practice.
2. Readiness reduces irresponsible uncertainty.
3. Ready does not mean fully known.
4. Evidence is stronger than a status label.
5. Dependency and environment readiness require validation.
6. Risk should determine checklist depth.
7. Spikes answer decision-blocking questions.
8. A large ready queue creates stale analysis.
9. Senior engineers should enable shared judgment.
10. Internal readiness rules must be verified.

70. References

Conceptual baseline:

• The Scrum Guide for Product Backlog refinement and Sprint selection context.
• General Agile readiness, story refinement, risk reduction, and dependency-management practices.

Definition of Ready is not a formal Scrum commitment, and these concepts do not describe internal CSG processes.