Convergence as Tech Debt Safeguard

Managing technical debt is never an easy game. Even if we have ideas, we need to compare the impact with the product initiatives/feature that we need to build to ensure we stay strong on the product side and boost the business. So what to do? lo and behold : Diverge-Convergence, comes as one of the strategies.

Each Sprint diverged into two streams: shaping & building, execute convergence sprint every triples.


Divergence is a concept of splitting task assignments into two streams: Shaping and Building. Note that it doesn’t mean that every sprint must have both streams at the same time; there might be a sprint that only has either building or shaping streams only.

Divergence is intended to set boundaries to ensure the engineer assigned as a builder (building stream) only focus on building feature while shaper (shaping stream) is helping builder to focus by handling the production bugs/inquiries for planning (i.e., requirements gathering, RFC, Post Mortem).

An exceptional case might be triggered in case of emergency i.e., critical bug fix that requires an engineer who happened to be a builder.

  • Shaping
    • Gathering requirements, RFC & PRD refining.
    • Production Bug fixing.
  • Building
    • Uninterrupted work on Product & Engineering initiatives.
    • For any production, issue bugs redirect to Shaper (engineer whos in shaping mode)


  • convergence is a sprint wrap-up, listening to feedback from various channels (i.e. slack, user complaint) and bringing bugs, critical tech debt & must-have improvements to zero
  • converge may have feature development if it’s being carried over from the last sprint. no new feature work picked up during the convergence sprint unless exceptional.
  • prior to the convergence sprint, the engineer/TPM/product may allocate or plan the findings from the running sprint to be fixed during convergence.
  • all bugs or work is prioritized in the following categories:
    • P0 – Blocks Ship/All Hands on deck.
    • P1 – Critical Fixes & Technical Debt
    • P2 – Nice to Have
    • P3/4 – Things to look into but neither nice to have nor critical fixes.
    • P5 – Unscreened.
    • P6 – Investigation bugs that we are not sure if P4 or higher.
  • The expected output of the convergence sprint:
    • 0 bugs backlog
    • Engineering Initiative Deliverable


Notify of
Inline Feedbacks
View all comments