journal

Ask-Based Planning: How to Actually Make Decisions in Software Teams 🎯

Stop overthinking. Start asking: “What’s the actual ask here?” 🤔

Every software project drowns in complexity—architectural debates, framework wars, process ceremonies. But what if we reduced everything to a simple question: What are we actually being asked to deliver?

The Fundamental Problem with Modern Planning 🔄

We’ve inverted the planning process. We start with:

When we should start with:

This isn’t settling for mediocrity. It’s acknowledging reality.

Why “Ask” Instead of Bug/Story/Task? 🏷️

Traditional issue tracking creates unnecessary complexity:

The Taxonomy Problem 📊

Teams waste hours debating:

Meanwhile, what actually matters:

The Status Game 🎮

Traditional categories create politics:

The Beautiful Simplicity of “Ask” ✨

Everything is just an ask:

No taxonomy arguments. Just evaluate each ask on its merits:

Real Example

Traditional Approach:

Type: Bug
Severity: P2
Component: Authentication
Labels: backend, security, customer-reported
Story Points: 5
Epic: User Management

Ask-Based Approach:

ASK: Users can't reset passwords
IMPACT: 50+ support tickets daily
EFFORT: 2 days
PRIORITY: 1 (blocking customers)
DECISION: Fix today

Which one helps you make decisions faster?

The Three Pillars of Ask-Based Planning 🏛️

1. Identify the Unmovables 🗿

Some things don’t change. Amazon built an empire on three constants:

These haven’t changed in 30 years. They won’t change in the next 30.

Your unmovables might be:

Stop chasing trends. Build around constants.

2. Map Your Actual Constraints 🗺️

Constraints aren’t limitations—they’re clarity. Every real project has:

Budget Constraints

Team Constraints

Time Constraints

Infrastructure Constraints

Acknowledge these. Plan around them. Stop pretending they’ll magically disappear.

3. Make Decisions Based on the Ask 🎲

Every technical decision should answer: “What are we being asked to deliver?”

Example: “Build a customer dashboard”

Traditional approach:

Ask-based approach:

The Decision Framework 🧭

For every technical choice, ask in this order:

  1. What’s the actual ask?
    • Not what you think they need
    • Not what would be cool to build
    • What they literally asked for
  2. What are our unmovable constraints?
    • Deadline (when must this ship?)
    • Budget (what can we actually spend?)
    • Team (who’s actually available?)
    • Technical (what systems must we use?)
  3. What’s the simplest solution that satisfies both?
    • Not the best solution
    • Not the most scalable solution
    • The solution that ships on time and works

Getting to the Real Ask: The 5 Whys 🔍

Most asks are symptoms, not root causes. Drill down to find what’s really needed:

Example 1: “We need a dashboard” 📊

Ask: “We need a real-time analytics dashboard”

Why 1: Why do you need a dashboard? → “To see our sales numbers”

Why 2: Why do you need to see sales numbers? → “To know if we’re hitting targets”

Why 3: Why don’t you know if you’re hitting targets? → “The reports come monthly and are always late”

Why 4: Why are reports monthly and late? → “Bob manually compiles them from 3 systems”

Why 5: Why does Bob manually compile them? → “The systems don’t talk to each other”

Real Ask: Automate data export from 3 systems (2 days work) Not: Build complex real-time dashboard (2 months work)

Example 2: “The system is slow” 🐌

Ask: “We need to rewrite the system for performance”

Why 1: Why do you think we need a rewrite? → “The system is too slow”

Why 2: Why is it slow? → “Pages take 10 seconds to load”

Why 3: Why do pages take 10 seconds? → “The database queries are slow”

Why 4: Why are the queries slow? → “We’re loading all customer history on every page”

Why 5: Why are we loading all history? → “The original developer thought we might need it”

Real Ask: Add pagination to customer history query (4 hours work) Not: Rewrite entire system (6 months work)

The Pattern 🔄

Surface ask → Often an expensive solution to a symptom Deep ask → Usually a simple fix to the root cause

Questions that reveal the real ask:

When to Stop Asking Why 🛑

Stop when you reach:

The Anti-Pattern: Solution Disguised as Ask ⚠️

Red flags:

Always translate to actual need:

Then ask: Is the proposed solution the simplest way to meet the actual need?

Real-World Applications 🌍

The “Investigation Budget” Approach 💰

Instead of endless analysis paralysis:

Time-boxed investigation with clear decision points.

The “Harvest vs. Perfect” Principle 🌾

Good enough that ships beats perfect that doesn’t.

The “Natural Organization” Pattern 🌳

Let constraints drive organization:

No complex ceremonies. Clear ownership based on expertise.

The Estimation Problem: Why Story Points Failed 📉

The Theater of False Precision 🎭

Traditional estimation creates elaborate rituals with no value:

Planning Poker

Velocity Tracking

What Estimates Actually Communicate 💬

The precision paradox reveals the truth:

“1 hour” = “I’ve done this exact thing before”

“2-3 days” = “I understand the problem”

“2 weeks” = “This is complex but I see the pieces”

“2 months” = “I have no idea”

The pattern: Long estimates are really saying “I don’t understand this yet.”

The Confidence-Based Approach 📊

Instead of false precision, be honest:

ASK: Add user profiles
ESTIMATE: 1-3 weeks
CONFIDENCE: Low (30%)
WHY LOW: Never built profiles, unsure about requirements
NEXT STEP: 2-day investigation to understand better

Investigation Budgets: Buying Certainty 🔬

When confidence is low, time-box investigation:

“Spend 2 days researching, then estimate” Better than: “It’ll take 2 months (maybe)”

“Build a prototype for 1 week, then decide” Better than: “The architecture might not work”

“Talk to 3 users, then scope it” Better than: “We think users want this”

Knowing When to Abandon 🚪

Set investigation limits upfront:

INVESTIGATION BUDGET: 1 week
ABANDON IF:
- Estimate exceeds 3 months
- Requires skills we don't have
- Third-party API doesn't support our needs
- Compliance requirements too complex

Don’t fall for sunk cost fallacy. Sometimes the best decision is “This isn’t worth it.”

Patterns Over Predictions 📈

Track what actually happens:

Use patterns to adjust future estimates, not story points to create velocity theater.

Training Teams in Ask-Based Thinking 🎓

Week 1: The Constants Exercise 📌

List what won’t change:

Week 2: The Constraint Audit 📋

Document reality:

Week 3: The Decision Practice 🎯

For every decision this week:

Week 4: The Retrospective Reality Check 🔍

The Priority Hierarchy That Makes Decisions Automatic ⚡

Stop debating. Use this order:

Priority 1: Does this block customers? 🚨

Priority 2: Legal/Security/Compliance Risk? ⚖️

Priority 3: Does this make/save significant money? 💵

Priority 4: Performance/Reliability Issues? 🏎️

Priority 5: Everything Else 📦

This eliminates arguments. Higher priority always wins. Most decisions make themselves.

The Triage Mindset: Medical Emergency Room for Software 🚑

Think like an ER doctor, not an architect:

Red (Immediate) 🔴

Yellow (Delayed) 🟡

Green (Walking Wounded) 🟢

Black (Expectant) ⚫

Triage Discipline:

The Pre-Ask Checklist: Right-Sizing Your Response 📏

Not every ask needs a full analysis. Triage first:

Trivial (< 1 hour) ⚡

Just do it. No analysis needed.

Simple (< 1 day) 🔧

Quick team check, then execute.

Standard (< 1 week) 📋

Use the basic framework:

Complex (> 1 week) 🏗️

Full analysis needed:

Strategic (Changes everything) 🚀

Board-level decision:

The rule: Match analysis effort to decision impact.

The Comprehensive Ask Parameters 📊

When you need full analysis, here’s what matters:

THE ASK: [What are we being asked to do?]

IMPACT ASSESSMENT:
- Users affected: [Number/percentage]
- Revenue impact: [Dollar amount if applicable]
- Risk if we don't: [What happens?]

EFFORT ASSESSMENT:
- Time estimate: [Days/weeks]
- People needed: [Who specifically]
- Complexity: [Simple/Medium/Complex]

CONSTRAINTS:
- Deadline: [Hard date or flexible]
- Dependencies: [What must happen first]
- Budget: [Cost in time/money]

PRIORITY CATEGORY: [1-5 from hierarchy above]

DECISION: [Do now/Do later/Don't do]
REASONING: [One sentence why]

Real Examples Using Priority + Triage 💡

ASK: Homepage loads in 8 seconds
PRIORITY: 4 (Performance issue)
TRIAGE: Yellow
DECISION: Fix next week

ASK: Users can't checkout
PRIORITY: 1 (Blocks customers)
TRIAGE: Red
DECISION: Drop everything now

ASK: Add dark mode
PRIORITY: 5 (Nice to have)
TRIAGE: Green
DECISION: Backlog

ASK: GDPR compliance gap
PRIORITY: 2 (Legal risk)
TRIAGE: Yellow/Red depending on deadline
DECISION: Fix this week

Risk Assessment: Know What Can Go Wrong ⚠️

Every ask has risk. Identify it upfront:

Technical Risks 🔧

Business Risks 💼

Operational Risks ⚙️

Risk Levels and Response 🎚️

Low Risk (Green Light)

Medium Risk (Yellow Light)

High Risk (Red Light)

Risk Mitigation Strategies 🛡️

For Technical Risks:

For Business Risks:

For Operational Risks:

The Cost-Benefit Reality Check 💰

Always ask: “Is the juice worth the squeeze?”

The Risk-Adjusted Matrix 📊

  Low Risk High Risk
High Impact Do Now Plan Carefully
Low Impact Do Later Don’t Do

High Impact, Low Risk (Quick Wins) 🎯

Do immediately. These fund everything else.

High Impact, High Risk (Strategic Bets) 🎲

Plan carefully, prototype first, monitor closely.

Low Impact, Low Risk (Cleanup) 🧹

Do during slow periods or assign to juniors.

Low Impact, High Risk (Danger Zone) ☠️

Just say no. These kill teams.

Common Objections (And Responses) 💬

“This promotes technical debt!” No, it acknowledges reality. Perfect systems that never ship create infinite technical debt.

“We should build for scale!” When you need scale. Most systems die before reaching scale problems.

“This isn’t engineering excellence!” Engineering excellence is delivering value within constraints. NASA didn’t have unlimited budgets either.

“What about best practices?” Best practices assume standard conditions. Your conditions aren’t standard.

The Leadership Shift 👔

Traditional leadership asks:

Ask-based leadership asks:

Practical Templates 📝

Daily Decision Template 📅

THE ASK: [What are we being asked to do?]
UNMOVABLE DEADLINE: [When must this be done?]
AVAILABLE RESOURCES: [Who/what do we have?]
SIMPLEST SOLUTION: [What gets us there?]
DECISION: [What we're doing]

Project Planning Template 📊

BUSINESS ASK: [What does the business need?]
USER ASK: [What do users need?]

CONSTRAINTS:
- Budget: [Actual money available]
- Team: [Actual people available]
- Time: [Actual deadline]
- Technical: [Systems we must use]

PROPOSED SOLUTION: [Simplest thing that satisfies ask within constraints]

SUCCESS CRITERIA: [How we know we delivered the ask]

The Meta-Truth About Ask-Based Planning 🎯

It’s not about lowering standards. It’s about hitting targets.

An Olympic archer doesn’t debate arrow metallurgy during the competition. They identify the target, account for wind (constraints), and shoot.

Software teams spend so much time perfecting their bow, they forget to aim.

Kanban and Ask-Based Planning: Perfect Together 🤝

Why Kanban Works for Asks ✅

Kanban’s simplicity aligns perfectly with ask-based thinking:

Visual Reality

Natural Flow

The Simple Ask Board 📋

| BACKLOG | READY | WORKING | REVIEW | DONE |
|---------|-------|---------|--------|------|
| Dark    | Login | Payment | Search |      |
| mode    | fix   | API     | update |      |
|         |       | 🔴 Day 5 |        |      |
| Export  | Cache |         |        |      |
| feature | bug   |         |        |      |

Key Rules:

  1. Limit WIP: Max 2-3 asks in WORKING per developer
  2. Pull, don’t push: Take work when ready, not when assigned
  3. Flow metrics: Track how long asks take, not points
  4. Blockage = Emergency: Red dot means all-hands response

When Flow Stops: Emergency Protocol 🚨

Blocked Ask Response:

ASK: Payment API integration
STATUS: 🔴 Blocked Day 5
PROBLEM: Third-party docs incorrect
RESPONSE:
1. Stop new work entering WORKING
2. Swarm the problem (multiple people investigate)
3. Time-box solution attempt (2 days max)
4. Abandon if unsolvable (cut losses)

Flow Patterns Tell Truth 📊

After a month, patterns emerge:

Use patterns to improve:

Kanban Eliminates Estimation Theater 🎭

No story points needed.

Track only what matters:

The Beautiful Simplicity ✨

Traditional Scrum + Jira:

Kanban + Asks:

Start Tomorrow 🚀

Pick one decision you’re facing. Apply the framework:

  1. What’s the actual ask?
  2. What constraints are real?
  3. What’s the simplest solution?

Then ship it.

Because at the end of the day, working software that solves real problems beats architectural diagrams every time. Your users don’t care about your design patterns. They care that it works, it’s fast, and it solves their problem.

Ask what they’re asking for. Acknowledge your constraints. Deliver what works.

That’s ask-based planning.

Remember: Constraints aren’t the enemy of creativity—they’re its catalyst. Every masterpiece was created within constraints. Your software can be too. 🎨