DEV Community

Cover image for How I Plan Software Deliveries (Team-Solo Method)
Joao Kersul
Joao Kersul

Posted on • Edited on

How I Plan Software Deliveries (Team-Solo Method)

#projectmanagement #agile #architecture #leadership

TL;DR

The Team-Solo Method breaks big, messy features into five clear steps, switching between working together (Team) and working alone (Solo).

  1. Map the problem with the whole team.
  2. On your own, list every open question.
  3. Meet again to check the plan and hand out the tough bits.
  4. Solve the unknowns and turn them into clear tasks.
  5. Lock the timeline and success metrics.

Handle risks early so scope stays clear and deadlines stick.

The Team-Solo Method

Context

Big features die in the gap between idea and execution. Without a clear roadmap, you either over-spec and stall or under-spec and blow up the timeline. The Team-Solo Method dodges both traps by alternating between focused group sessions (Team) and heads-down deep work (Solo).

When to Use It

Reach for this method when the work changes architecture, data contracts, or organizational boundaries. Bug fixes and small UI tweaks don’t need this much ceremony.

Team-Solo Steps

1. Define the Domain (Team)

Kick off with the whole squad in the same (physical or virtual) room and make the domain crystal-clear.

Agenda

  1. Frame the problem (5 min). Desired outcome, constraints, non-goals.
  2. Map the domain (30 min). Brainstorm events, commands, policies—Event Storming works great here.
  3. Scope check (10 min). Explicitly mark what’s out for the first release.
  4. Name things (10 min). Agree on ubiquitous language and key aggregates.

Expected Output

  • A high-level domain map everyone understands.
  • A shared glossary of entities and aggregates.
  • A starter list of known unknowns to investigate later.

2. Organize Ideas and Challenges (Solo)

Step away from the noise and turn the raw domain artifacts into actionable insights.

  1. Cluster related concepts. Reveal implicit modules and bounded contexts.
  2. Surface unknowns. Anything fuzzy becomes a spike task.
  3. Spot quick wins. Identify slices that deliver value early.
  4. Sketch architecture. Lo-fi boxes and arrows—focus on seams and data flow.

⚠️ If something feels vague, write “VAGUE” on it—future you will thank present you.

Expected Output

  • A Challenge Backlog listing every spike with an owner placeholder.
  • First-cut architecture diagram.
  • Draft roadmap sliced by value.

3. First Debrief with Tech Team (Team)

Time to stress-test the draft with the people who will build it.

Agenda

  1. Walkthrough (15 min). Present clusters, spikes, straw-man architecture, roadmap.
  2. Open critique (20 min). Teammates poke holes, raise risks, suggest alternatives.
  3. Spike commitment (10 min). Assign owners and deadlines to each unknown.
  4. Definition of Done (5 min). Agree what version 1 means.

Expected Output

  • Challenge list with owners and due dates.
  • Provisional architectural direction.
  • Time-box for the next Solo phase (e.g., 3 working days).
  • Parking-lot questions to revisit later.

4. Solve Tech Challenges & Create Stories (Solo)

Engineers disappear into their caves (or pair rooms) to kill the unknowns.

  • Build throw-away proofs-of-concept to validate libraries, latency, migrations, etc.
  • Convert validated chunks into user stories or technical tasks with estimates.
  • Document decisions and rationale.
  • Escalate if a spike breaches its time-box—don’t boil the ocean.

Expected Output

  • All spikes closed, questions answered.
  • Backlog of ready-for-refinement stories with initial estimates.
  • Updated architecture diagram reflecting discoveries.

5. Final Refine Together (Team)

The “Go / No-Go” checkpoint where ideas become a committed delivery plan.

Agenda

  1. Refine stories (20 min). Apply INVEST, tighten acceptance criteria, right-size slices.
  2. Group estimation (15 min). Planning Poker or similar.
  3. Scope cut / pad (10 min). If the numbers don’t fit, negotiate scope, not quality.
  4. Lock release plan (10 min). Map stories to sprints, set milestones, assign DRIs.
  5. Define success metrics (5 min). Performance, adoption, whatever matters—write it down.

Expected Output

  • Refined backlog ordered by value.
  • Release timeline the whole team believes.
  • Clear success metrics and monitoring plan.

Why This Works

  • Fast feedback loops. No phase lasts long enough for you to drift too far off course.
  • Asymmetric collaboration. Meet only when group intelligence is needed; protect deep-work time otherwise.
  • Risk becomes work. Unknowns transform into dated spike tasks you can burn down.
  • Trust through visibility. Stakeholders see tangible artefacts at every checkpoint—boards, diagrams, backlog, metrics.

Common Pitfalls (and How to Dodge Them)

Pitfall Consequence Fix
Treating spikes as optional Surprises mid-sprint Time-box and track them like any other work
Skipping the Final Refine “Half-baked” stories enter sprint Make it a release gate
Over-documenting early Analysis paralysis Capture just enough to unblock the next phase

Conclusion

Big features aren’t hard because the code is hard—they’re hard because the unknowns are hidden. The Team-Solo Method shines a light on those uncertainties, turns them into actionable tasks, and keeps the team oscillating between collective alignment and focused execution. Steal it, adapt it, and watch your next architecture-level delivery land on time and on target.

Cut through uncertainty, surface risks early, and keep moving—that’s the whole game.

Top comments (0)