By Glue Team

Glue for Engineering Planning

Sprint planning is a time sink:

Leads sit in a room and assign stories. Estimates are guesses: "Looks like 3 weeks." Reality is unknown: blast radius, dependencies, hidden complexity, tech debt in affected code.

Six weeks in, the sprint is behind. Why? The "3-week" estimate was actually 4 weeks of new work plus 2 weeks of refactoring legacy code. If that complexity had been visible upfront, the team would have pulled fewer items and made the sprint.

Glue makes planning faster and more accurate by surfacing codebase data: complexity, dependencies, and technical debt in code being changed.

The Planning Problem

Sprint planning based on story names is unreliable:

Average variance: ±30%. This variance compounds across the sprint.

How Glue Improves Planning

Before planning, engineers use Glue to analyze stories:

Complexity assessment: For "Add user export feature," Glue shows:

• "User module has 12 related files, cyclomatic complexity 18 (high)"
• "Test coverage 45% (low)—expect refactoring and rework"
• "Similar export feature in payments module took 6 days and required 2 days post-launch fixes"
• "Estimate: 8 days, not 5"

Dependency visibility: Before committing to a story, engineers see:

• "This feature requires database schema changes; QA environment won't match production until migration is tested"
• "This change touches 5 other services; integration testing must happen serially"
• "Payment service change is blocking 3 other stories; do it first"

Blast radius assessment: Engineers understand the risk:

• "This change affects payment processing. High stakes. Requires senior engineer review."
• "Low-risk change; no other code depends on it. Anyone can own it."

Technical debt surfacing: Glue highlights refactoring needed:

• "Legacy auth module is in the critical path. Recommend 2 weeks refactoring before shipping dependent features."
• "Test coverage in this area is 30%. Allocate time for test writing alongside feature work."

Planning With Glue: Example Sprint

Stories to plan:

• A: User export (marketing request)
• B: Fix password reset (critical bug)
• C: Bulk user invite
• D: Stripe webhook timeout handling

Without Glue (guesses):

• A: 5 points
• B: 3 points
• C: 5 points
• D: 3 points
• Total: 16 points. Team velocity is 40 points, so "there's room for 24 more points."

With Glue (informed):

• A: 8 points (touches legacy code, needs refactoring)
• B: 5 points (low test coverage, bug in multiple places)
• C: 8 points (depends on A; sequence matters)
• D: 3 points (isolated change, low risk)
• Total: 24 points. Team velocity is 40 points, so realistic capacity is 16 more points.

With Glue, the team commits to high-confidence 24 points instead of optimistic 16 points and missing. Accountability and morale improve.

Maximizing Planning Effectiveness

1. Use Glue during refinement: Before sprint planning, engineers use Glue to estimate and flag risks. Refinement surfaces unknowns so planning is informed.

2. Call out dependencies: Glue shows service dependencies. Sequence stories so blockers are clear: Do this first, then that.

3. Allocate refactoring time: If Glue surfaces 3 weeks of refactoring needed for a feature, plan it. Don't hide it in estimation.

4. Track estimation accuracy: After each sprint, compare Glue's estimates to actuals. Improve the model over time.

Real-World Impact

Before Glue: Sprint is planned optimistically. 40-point commitment; 28 completed. Miss 30% of sprint.

After Glue: Sprint is planned realistically. 35-point commitment; 34 completed. Miss 2%. Morale, predictability, and momentum improve.

---

Frequently Asked Questions

Q: Will using Glue estimates make planning slower because we're being conservative? A: Initially, yes—you move from false optimism to realistic planning. But within 2-3 sprints, you hit velocity targets consistently. Predictability is better than optimism + missing.

Q: What if Glue's estimate is higher than the engineer's intuition? A: That's data suggesting hidden complexity. Investigation often reveals why (dependencies, legacy code, tech debt). Trusting data over intuition leads to better outcomes.

Q: How do we use Glue to estimate stories that haven't been written yet? A: Glue analyzes similar past work (if it exists) and shows patterns. For entirely new work, Glue estimates based on codebase characteristics (complexity of related code). Uncertainty is higher, so add a buffer.