Retro Summary

Today's retro focused on how we handled the ProvMns epic story to find out how we can improve our process internally in the team and working with E//.

ProvMns epic story history

Key Findings & Root Causes

1. Documentation Issues

• Finding: Wiki page document did not have any clarifying text on some examples such as the Configuration Management Input vs ProvMns Input

• Root Cause: Mapping was communicated as set of examples rather than a strict requirement

• Impact: Examples were modified during discussions on calls with no record of backgrounds/context of what the examples meant

• Lesson: JSON files should not have been enough for a requirement. Team needs a format such as this example, wherein JSON fields are individually assessed

2. Requirements Management Failures

• Finding

  • We did not capture enough what the requirement meant for the integration of policy

  • No RE-grooming happened as the requirements changed or open issues resolved

  • E\\ gives requirements based on 'assumptions' or based on studies/undefined/not yet implemented interfaces

• Impact: Scope creep and unclear deliverables throughout the project

3. Team Collaboration Gaps

• Finding

  • No review of the wiki page - not good enough if author gets hit by a bus

  • No other members in team questioned the acceptance criteria or clarified understanding during grooming meetings

• Impact: Single point of failure and missed opportunities to catch issues early

4. Process Breakdown

• Finding

  • Any change or new requirements, issues, blockers that arose - the main wiki page was not updated with dates

  • Change of priorities put pressure on the delivery

• Impact: Lost context and increased technical debt

Recommendations for Better Handling

Immediate Actions

1. Implement Living Documentation Standard

   • Update wiki pages within 24 hours of any requirement change, decision, or blocker

   • Include date stamps for all updates

   • Maintain a "Change Log" section at the top of each epic page

   • Use structured format for requirements (not just JSON examples)

2. Establish Testing Checkpoints

   • Define mandatory testing gates: after each major component completion

   • Involve stakeholder teams (like policy executor) for integration testing early

   • Create test sign-off checklist before moving to next phase

3. Clarify Integration Scope Upfront

   • Identify all integration points during initial grooming

   • Create separate epics for complex integrations

   • Document integration assumptions and validate them early

Process Improvements

4. Mandatory Peer Review Process

   • All epic wiki pages must be reviewed by at least 2 team members

   • Schedule wiki review sessions during sprint planning

   • Use "bus factor" test: can someone else take over with just the wiki?

5. Enhanced Grooming Practices

   • Require at least 2 team members to actively question acceptance criteria

   • Re-groom when requirements change significantly (>20% scope change)

   • Document all assumptions and validate them with stakeholders

   • Create "Definition of Ready" checklist for epics

6. Stakeholder Engagement Protocol

   • Identify key stakeholders and their availability windows upfront

   • Schedule regular sync points (weekly for complex epics)

   • Escalate early if stakeholder is unavailable for >3 days on critical questions

   • Document all verbal discussions in wiki within same day

Strategic Changes

7. Requirements Documentation Template

   • Adopt structured format similar to CM Subscriptions example

   • Include: field-by-field analysis, use cases, error scenarios, integration points

   • Require sign-off from both CPS team and E\\ before implementation starts

8. Early Research Phase

   • Allocate 1-2 sprints for research on 3GPP specs and standards

   • Document possible scenarios and edge cases before implementation

   • Create error scenario catalog early in the epic lifecycle

9. Risk Management Framework

   • Identify risks during initial grooming (licensing, team size, dependencies)

   • Create mitigation plans for high-impact risks

   • Review risk register bi-weekly

10. Cross-Team Integration Protocol

    • For any epic requiring integration with another team:

      • Create separate integration epic

      • Define clear interface contracts upfront

      • Schedule joint planning sessions

      • Establish shared testing environments early

Actions

Success Metrics

To measure improvement, track:

• Wiki update frequency (target: within 24 hours of changes)

• Number of re-grooming sessions (should increase when scope changes)

• Peer review completion rate (target: 100%)

• Stakeholder response time (target: <2 days)

• Testing checkpoint completion (target: 100% before next phase)

• Post-delivery bug count (target: reduce by 50%)

‌