Remote Work Tools

Sprint planning in remote teams fails when it tries to replicate in-person planning ceremonies over video. A 2-hour Zoom call with 8 engineers estimating stories one by one is exhausting and ineffective. Async-first sprint planning — with a short synchronous alignment call at the end — works better. This guide covers the tools and the workflow.

Table of Contents

The Async-First Sprint Planning Workflow

The pattern that works for most remote teams:

Day -3 (Monday): Product manager publishes sprint candidates in the backlog tool
Day -2 (Tuesday): Engineers async-review stories, ask clarifying questions, flag risks
Day -1 (Wednesday): Engineers async-estimate (poker or t-shirt sizing)
Day 0 (Thursday): 30-minute sync call to confirm sprint scope and resolve disagreements

The sync call should not be estimating stories from scratch. It should be “here’s the sprint, does anyone have objections or concerns?”

Tool 1: Linear

Linear is the best choice for engineering-focused remote teams that want speed and simplicity.

Setup for async sprint planning:

Workspace → Teams → [Your Team] → Cycles (Linear's term for sprints)

Cycle settings:
- Duration: 2 weeks
- Auto-close on cycle end: No (manually close to review)
- Notifications: Mention or assignment only (not all activity)

Linear async estimation via keyboard shortcuts:

1. During backlog review, each engineer opens issues assigned to review
2. Add estimate directly: press E in an issue, select point value
3. Use labels for confidence: "needs-discussion", "ready-to-ship"
4. Flag blockers with a comment: @pm-name what's the expected API response for null state?

Estimation scale: Fibonacci (1, 2, 3, 5, 8, 13)
- 1: < 2 hours
- 2: half day
- 3: 1 day
- 5: 2-3 days
- 8: 4-5 days
- 13: break this down, it's too big

Linear sprint start checklist:

## Sprint Start Checklist

Completed by PM 3 days before sprint start:
- [ ] Sprint candidates added to backlog
- [ ] Each issue has: description, acceptance criteria, design link if applicable
- [ ] Dependencies flagged on blocked issues

Completed by engineers 1 day before sprint start (async):
- [ ] All sprint candidates estimated
- [ ] Questions posted as comments (not DMs)
- [ ] "needs-discussion" label on anything unclear

Completed in sync call:
- [ ] Sprint scope confirmed (fit into team velocity)
- [ ] "needs-discussion" items resolved or deferred
- [ ] Sprint started in Linear

Linear velocity tracking:

Linear’s built-in cycle reports show:

# Linear API: fetch velocity data for last 5 cycles
curl -X POST https://api.linear.app/graphql \
  -H "Authorization: $LINEAR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "query {
      cycles(filter: {team: {key: {eq: \"ENG\"}}}, last: 5) {
        nodes {
          id
          number
          startsAt
          endsAt
          completedAt
          issues(filter: {completedAt: {gt: \"2026-01-01\"}}) {
            nodes {
              estimate
              completedAt
            }
          }
        }
      }
    }"
  }'

Tool 2: Jira

Jira is the default for larger organizations and teams that need compliance, reporting, or Jira-integrated workflows.

Async planning in Jira:

Use Jira’s Planning Board (formerly Backlog view):

Before sprint start:
1. PM moves issues to "Ready for Sprint" status
2. PM posts link in Slack: "Sprint candidates ready for review: [Jira link]"
3. Engineers have 24h to estimate and comment
4. Use Jira's Story Points field for estimates
5. Use a custom field "Estimate Confidence" (select: High/Medium/Low)
6. Low confidence items get auto-flagged for discussion

Jira automation for sprint planning:

// Automation rule: notify when sprint candidate needs estimate
{
  "trigger": "Status changed to 'Ready for Sprint'",
  "conditions": [
    {"field": "Story Points", "operator": "is empty"}
  ],
  "actions": [
    {
      "type": "Send Slack message",
      "channel": "#team-platform",
      "message": "Needs estimate: {{issue.summary}} — {{issue.url}}"
    }
  ]
}

Jira sprint reports to track:

Check the sprint report in your retrospective, not the burndown in daily standups — daily burndown obsession leads to gaming the system.

Tool 3: Notion for Sprint Documentation

Notion isn’t a sprint management tool, but it’s the right place for sprint documentation: goals, decisions, retrospective notes, and the sprint narrative.

Sprint page template:

# Sprint 42 — 2026-03-22 to 2026-04-04

**Goal:** Ship the new checkout flow with new payment methods

## Team Capacity
| Engineer | Days available | Notes |
|---|---|---|
| @alice | 9 | PTO Friday |
| @bob | 10 | |
| @carol | 8 | On-call Wednesday |

**Total capacity:** 27 engineer-days

## Sprint Scope (committed)
Estimated: 34 points (based on 12pt/engineer avg × 3 engineers)

**Must complete (committed):**
- [PLAT-456] Stripe Apple Pay integration (5pt)
- [PLAT-460] Checkout error state redesign (3pt)
- [PLAT-462] Payment failure retry logic (8pt)

**Stretch goals (if time allows):**
- [PLAT-470] Analytics events for checkout funnel (5pt)

## Sprint Decision Log
| Decision | Reason | Date |
|---|---|---|
| Defer PLAT-465 (Google Pay) | Blocked on API access | 2026-03-22 |

## Post-Sprint Review (filled in after sprint)
Completed: X points (Y%)
Not completed: [issues]
Carry-over: [issues]

Tool Comparison: Linear vs Jira vs Height

Choosing the right tool matters more for remote teams than co-located ones — friction in async workflows compounds. Here is how the main options compare across the factors that matter most:

Factor Linear Jira Height
Setup time 30 minutes 2-4 hours 1 hour
Async estimation UX Inline, keyboard-first Requires clicking into each issue Inline, fast
Automation / rules Basic Extensive (Automation for Jira) Moderate
Reporting / velocity Built-in cycle reports Rich (burndown, velocity, CFD) Basic
GitHub integration Excellent (auto-closes issues) Good (with Jira GitHub app) Good
Price per user/mo $8 $8.15 (Standard) $6.99
Best for Engineering-focused startups Enterprise / compliance-heavy Small product teams

Linear wins for developer experience. Jira wins when you need integration with enterprise tooling (Confluence, ServiceNow, Salesforce) or complex reporting dashboards for non-engineering stakeholders. Height is worth a look for teams that find both too heavy or too light respectively.

Estimation Anti-Patterns

Planning poker by video: 8 engineers in a Zoom call showing cards is painful. Use PlanningPoker.com or Linear’s built-in estimation — engineers submit estimates independently, then compare.

Relative estimation drift: After 6 months, your “3 points” inflates to what used to be “5 points.” Recalibrate quarterly by comparing current 3-point stories to historical ones.

Estimating everything: Not every story needs a point estimate. Bugs and operational tasks (security updates, dependency bumps) don’t need estimation — they go into a time budget (e.g., “10% of sprint capacity for ops”). Only estimate feature work.

Velocity as a performance metric: Velocity is a capacity planning tool, not a productivity metric. Publishing individual velocity data creates story-padding behavior.

PlanningPoker.com for Async Estimation

For teams that want consensus estimation without a meeting:

1. Create a session at planningpoker.com
2. Paste session link in Slack with the sprint candidate list
3. Engineers vote asynchronously over 24 hours
4. Review results: if all votes within one Fibonacci value → use average
   If wide spread → discussion comment required on the issue
5. PM updates estimates in Linear/Jira based on consensus

Async Estimation Challenges and Solutions

Challenge 1: Wide variance in estimates

When engineers estimate asynchronously, you often see 3-point estimates and 13-point estimates for the same story. This indicates the story isn’t clear.

Solution: Require comments on wide spreads
- If range > 1 Fibonacci level, flag for discussion
- Example: If you see [3, 3, 8, 5, 5], ask 8-point estimator why
- Often reveals missing information or scope

Slack message template:
"Story [XYZ] got estimates 3, 5, 5, 8, 5.
@sarah — you estimated 8 points. What's the hidden complexity?"

Result: Estimate converges after clarification

Challenge 2: Estimation confidence

Engineers estimate fast but aren’t confident when they haven’t seen all dependencies.

Solution: Confidence tracking (High/Medium/Low)
Use three fields in Linear/Jira:
- Points estimate
- Confidence level (radio button)
- Confidence reason (text)

Triage decisions:
- High confidence estimates: Start work immediately
- Low confidence estimates: Defer until clarified
- Medium confidence: Assign tech lead to pair first day

Challenge 3: Blocked stories that slip through

A story gets estimated but has a dependency on another team’s work that’s not scheduled yet.

Solution: Dependency blocking workflow

Before sprint confirmation:
1. Filter all stories to show "depends_on" field
2. For each dependency, verify:
   - Owner team has it scheduled
   - Owner committed to delivery date
   - Blocker is documented in the story
3. If uncertain, move to backlog (don't force into sprint)

Example story with dependency:
Title: "Implement Stripe payment processing"
Depends on: [BILLING-456] "Design payment status API"
Owner: @billing-team
Committed delivery: March 29, 2026
Risk: If BILLING-456 slips, this blocks implementation

Velocity Anti-Patterns and Fixes

Anti-pattern 1: Velocity inflation

Velocity starts at 28 points/sprint, creeps to 45 points/sprint over months. But actual feature output doesn’t increase. The points are inflating.

Root cause: Story size definition drifts over time
Fix:
1. Recalibrate every 6 months
2. Compare current "5-point" story to "5-point" story from 6 months ago
3. Reset scale if drift > 20%

Example recalibration:
Old baseline: "5 points = 1 day of a senior engineer"
New baseline: "5 points = 6-8 hours of a senior engineer" (drifted to larger)

Reset: Divide all old estimates by 1.3, recalibrate new baseline

Anti-pattern 2: Velocity used for performance evaluation

Manager says: “You committed 32 points, only completed 24. Why?”

This creates story-padding behavior where engineers estimate conservatively.

Fix: Separate velocity (planning tool) from performance (individual evaluation)
Metrics for performance:
- Code quality (review comments, bug rate)
- Delivery reliability (on-time completion rates)
- Collaboration (PR review turnaround, helping teammates)

Velocity is for:
- Sprint planning (capacity allocation)
- Long-term roadmap forecasting
- Identifying process improvements
- NOT individual performance

Scaling Sprint Planning Across Multiple Teams

When you have 3+ engineering teams, coordinate sprints to prevent misalignment:

## Multi-Team Sprint Planning Process

**-2 weeks before sprint:**
- Product leads align on priorities across teams
- Identify cross-team dependencies
- Highlight conflicts (two teams wanting the same resource)

**-1 week before sprint:**
- Each team creates sprint candidates
- Product lead reviews for conflicts/overlaps
- Resolve: defer lower-priority story or re-assign people

**-3 days before sprint:**
- All stories written, with clear acceptance criteria
- All cross-team dependencies documented
- Stories ready for engineering review

**-1 day before sprint:**
- Engineers async-review and estimate
- Flag unclear stories or dependencies
- PM resolves questions async (no meeting if possible)

**Sprint day:**
- 30-min sync: Confirm scope, resolve any final disagreements
- Start sprint immediately after (no waiting)

## Cross-team dependency tracking

| Blocked Story | Blocking Story | Owner | Delivery Date | Risk |
|---|---|---|---|---|
| FRONTEND-123 | API-456 | Backend | Mar 29 | High (blocking FE) |
| MOBILE-789 | API-456 | Backend | Mar 29 | High (blocking two) |

If a blocking story slips, all dependent stories slip. Escalate blocking stories as risks in sprint planning.

Built by theluckystrike — More at zovo.one

Explore Our Developer Guides

© 2026 theluckystrike Developer Guides