Saeed Saedi Get in touch
← All work

Case study · Kifpool.me · Delivery

From one sprint plan to service ownership

Thirty-one microservices shared one sprint plan, and cross-team dependencies kept surfacing halfway through the sprint. I moved delivery to service-level ownership and mapped dependencies before each sprint started. Cross-team blockers fell by 30%, and releases became more predictable.

Role
Technical Product Manager
Team
20 engineers, 3 squads
Scope
31 microservices
Result
−30% cross-team blockers
BEFORE One sprint plan, 31 services SPRINT blocked dependency AFTER 3 squads, clear owners BACKENDINFRABLOCKCHAIN explicit dependency owner
Before: one plan across every service, with dependencies found mid-sprint. After: three squads that own their services, with dependencies agreed up front. Illustrative.

The situation

Kifpool.me is a cryptocurrency exchange with more than two million users. Behind it are 31 microservices, from the exchange engine and order management to pricing and blockchain integrations. Twenty engineers build them in three squads: backend, infrastructure and blockchain. We work in two-week sprints.

The problem

Planning happened as one sprint for everyone. Each engineer planned their own piece, but nobody owned the picture across services. When a feature touched two or three services, the dependency usually showed up halfway through the sprint: one service changed a contract that another was already building against. Both slipped, and the sprint goal slipped with them.

In a system this size, that pattern was the biggest single reason sprint goals were missed.

What I did

  • Every service has an owner. Each squad owns its services end to end, from planning to release, so someone is always accountable for a change and its effects.
  • Dependencies are mapped before the sprint, not during it. Any feature that touches more than one service gets a dependency map at planning, and shared API contracts are agreed before parallel work starts.
  • Slips show up early. A short check on day six of each sprint, plus a “cut first if tight” list, means we adjust while there is still time.
  • Commitments match capacity. Velocity from past sprints sets how much we take on, so plans are realistic from the start.
“Dependency management means catching the collision on day zero, not day eight.”

Results

−30%cross-team dependency blockers
95%+on-time delivery across 31 services
Earlierconflicts now surface at planning instead of mid-sprint

What I learned

Most delivery delays are coordination problems that look like engineering problems. Making ownership and dependencies explicit did more for our speed than any push to work faster.