Can You Use Planning Poker for Hardware and Physical Products?

“Planning Poker Doesn’t Work for Hardware” – Actually, It Can (If You Stop Treating It Like Software)

If you’ve ever tried to run Planning Poker with a hardware or physical product team, you’ve probably hit this wall:

“We can’t estimate like software. Lead times, suppliers, tooling, compliance… this is different.”

You’re right. Hardware is different. But that doesn’t mean Planning Poker is useless. It means you’re using it wrong.

Planning Poker is not about predicting exact dates. It’s about forcing a shared conversation about complexity, risk, and effort. That’s just as critical in hardware as in software—maybe more so, because your mistakes are literally baked into metal.

Let’s break down how to actually make Planning Poker work for hardware and physical products, without pretending your world looks like a web app.

Can You Use Planning Poker for Hardware? Yes — If You Redefine “Effort”

The biggest mistake teams make is trying to use Planning Poker for hardware the same way they do for pure software.

Why Traditional Story Points Break in Hardware

In software, story points usually combine:

Complexity
Uncertainty
Effort (time/energy)

In hardware, that’s not enough. You’re dealing with:

Physical constraints (material properties, tolerances, manufacturability)
External dependencies (suppliers, tooling vendors, testing labs)
Irreversible decisions (once you cut steel for a mold, changes are expensive)
Long feedback loops (you can’t “just deploy” a new PCB revision daily)

If you try to estimate “how long” something will take in story points, you’ll end up with:

Endless debates about “but the supplier might delay us”
Story points that are secretly just time estimates in disguise
A backlog full of lies no one trusts

Redefine What You’re Estimating

For hardware and physical products, Planning Poker works best when you estimate:

Engineering/design effort – how much thinking, modeling, and iteration will the team need?
Integration complexity – how many systems, interfaces, and disciplines are involved?
Risk and uncertainty – how much is unknown, and how painful will it be if we’re wrong?

You are not estimating:

Supplier lead times
Manufacturing cycle times
Regulatory approval durations

Those belong in a delivery plan, not in story points.

A practical pattern:

“Our story points reflect engineering effort + technical risk within our control, not calendar time.”

This small shift makes Planning Poker usable in hardware environments.

How Planning Poker Actually Helps Hardware Teams

Done right, Planning Poker can solve real pain points hardware teams complain about all the time.

Pain Point #1: “We Always Underestimate NRE and Prototyping”

Non-recurring engineering (NRE) and prototyping are where hardware projects quietly bleed to death.

Typical scenario:

A “simple” mechanical change gets 3 points.
Turns out it needs two prototype iterations, test jigs, and coordination with a supplier.
You blow the schedule and everyone blames “manufacturing” or “supply chain.”

With Planning Poker, the disagreement in estimates is the gold.

Example:

Story: “Redesign the bracket to support 2x load and pass vibration testing.”

Mechanical engineer plays: 3
Test engineer plays: 8
Manufacturing engineer plays: 13

Instead of averaging, you ask:

“Why 3?” → “We already have a similar design. It’s a quick CAD tweak.”
“Why 13?” → “We’ve failed this vibration test twice before. We’ll need fixtures and at least two test cycles.”

Now you see the real work:

Design is easy.
Validating and proving it works is hard.

Outcome:

Story gets sized as 8 or 13.
You split out “Design change” vs “Test planning and execution.”
You adjust expectations before committing to dates.

Pain Point #2: Cross-Discipline Misalignment

Hardware teams are often siloed:

Mechanical
Electrical
Firmware
Manufacturing
Compliance / Regulatory

They each think their part is “the hard bit.”

Planning Poker forces them into the same conversation.

Example:

Story: “Add temperature sensor and log to internal memory.”

Firmware: 5 points (code + tests)
Electrical: 8 points (new sensor, layout changes, BOM impact)
Mechanical: 2 points (minor housing tweaks)

The discussion surfaces:

Firmware thought the sensor was “already chosen.”
Electrical knows the existing ADC channels are maxed.
Mechanical points out the housing has no free space near the heat source.

Without Planning Poker, this would have become a nasty surprise three weeks later.

Pain Point #3: Overconfidence in Early Phases

In concept and early design phases, teams are notoriously optimistic.

“It’s just a proof of concept.”
“We’ll refine it later.”
“Let’s not overthink it.”

Planning Poker can be used to flag uncertainty, not pretend it doesn’t exist.

Tactic:

Use higher point values to represent “we don’t know enough yet.”
When the team throws wildly different cards (e.g., 3, 8, 21), treat that as a signal to:
- Spike the riskiest assumption
- Do a quick experiment
- Talk to a supplier or test lab before committing

Adapting Planning Poker for Hardware: Concrete Examples

Example 1: Estimating a PCB Redesign

Backlog item: “Redesign PCB to accommodate new microcontroller and add CAN bus.”

Participants: EE, firmware, test, manufacturing.

Estimates played:

EE: 13
Firmware: 8
Test: 5
Manufacturing: 13

Discussion:

EE: “New MCU has different power rails and pinout; we’ll need rerouting and new power tree.”
Firmware: “We’ve used this MCU before; code port is moderate.”
Test: “Regression tests are mostly automated.”
Manufacturing: “New layout may require new test fixture and different panelization.”

Final approach:

Split into:
- “Redesign PCB for new MCU” – 13
- “Add CAN bus routing and validation” – 8
- “Update test fixture and manufacturing docs” – 8
Create a spike: “Confirm DFM with manufacturer” – timeboxed, no story points.

Result: Clearer work breakdown, reduced “oh, we forgot test fixtures” surprises.

Example 2: Mechanical Change with Tooling Impact

Backlog item: “Increase enclosure thickness for IP rating improvement.”

Estimates:

Mechanical: 5
Manufacturing: 21
Program manager: 3 (based on “just change the model”)

Discussion reveals:

Tooling changes will cost 6–8 weeks and significant money.
Existing assembly process might not work with thicker walls.
Regulatory testing may need to be repeated.

Outcome:

Story gets split into:
- “Evaluate impact of thickness change (DFM, tooling, assembly)” – 8
- “Implement CAD changes and update drawings” – 5
- “Coordinate tooling change with supplier” – tracked in project plan, not story points
Decision: Defer change until after next build or explore alternative sealing methods.

Planning Poker didn’t “fix” lead times—but it made the hidden cost visible early.

What Not to Do: Common Mistakes with Planning Poker in Hardware

Mistake 1: Treating Story Points as Calendar Time

If you say things like “1 point = 1 day” in hardware, you’re lying to yourself.

Don’t:

Map points directly to weeks or months.
Use points to “guarantee” delivery dates to executives.

Do:

Use points to compare relative effort between stories.
Use throughput (points per iteration) as a rough capacity signal, not a contract.

Mistake 2: Ignoring Non-Engineering Work

Hardware projects fail when you only estimate “design work” and ignore:

Supplier qualification
Tooling design and validation
Regulatory documentation
Test planning and setup

Bad pattern:

“We’ll just handle the documentation later.”

Good pattern:

Create explicit backlog items for:
- Test plans
- Compliance documentation
- Supplier engagement
Estimate them in Planning Poker like any other story.

Mistake 3: Estimating Huge, Vague “Features”

If your story is “Design new product enclosure,” Planning Poker will be pointless.

Break it down into things you can actually reason about:

“Define enclosure requirements and constraints”
“Create initial enclosure concept”
“Run thermal simulation on concept”
“Refine design based on simulation”
“Prepare drawings for prototype build”

Each of these is something the team can meaningfully size.

Mistake 4: Running Planning Poker Without the Right People

In hardware, missing one discipline in the room is dangerous.

Don’t run estimation sessions with:

Only mechanical engineers for a system that impacts electronics and firmware.
Only engineers and no one from test, manufacturing, or regulatory.

At minimum, include:

Design engineer(s) for the affected domain
Test/validation representative
Manufacturing / DFM representative for changes that touch production
Someone who understands regulatory/compliance impact (when relevant)

Practical Tips: How to Make Planning Poker Work for Hardware Teams

1. Define a Hardware-Specific Estimation Scale

Don’t copy your software team’s Fibonacci scale blindly.

You can still use Fibonacci (1, 2, 3, 5, 8, 13, 21…), but define what it means for your context.

Example calibration:

1 point: Trivial change, minimal risk, no cross-team impact.
3 points: Straightforward design work, known patterns, single discipline.
5 points: Moderate complexity, some uncertainty, maybe one dependency.
8 points: Multi-discipline, meaningful risk, likely iteration.
13+ points: Big unknowns, multiple dependencies, needs splitting or a spike.

Revisit and refine this every few sprints based on reality.

2. Separate “Engineering Effort” from “External Lead Time”

When estimating, explicitly ask:

“What part of this is our work?”
“What part is waiting for others?”

For example:

Story: “Order and validate new custom heat sink.”
- Engineering effort:
  - Define requirements
  - Work with supplier on design
  - Review and approve drawings
  - Plan and run validation tests
- Lead time:
  - Supplier quoting
  - Manufacturing
  - Shipping

Estimate only the engineering effort with Planning Poker. Track lead times separately in your project plan or delivery forecast.

3. Use Planning Poker for Risk Surfacing, Not Just Sizing

Before playing cards, ask:

“What could make this blow up?”
“What’s the scariest unknown here?”

Then, when estimates differ significantly, dig into those risks. Often you’ll discover:

Missing test equipment
Unvalidated assumptions about tolerances or material behavior
Supplier capacity or capability issues

Turn those into:

Spikes (timeboxed investigations)
Explicit backlog items
Clear “go/no-go” decision points

4. Combine Planning Poker with Prototyping Milestones

For hardware, you can align estimation with build phases:

EVT (Engineering Validation Test)
DVT (Design Validation Test)
PVT (Production Validation Test)

Use Planning Poker to:

Estimate work required to reach each milestone.
Clarify what “done” means at each phase (e.g., for EVT: “mechanically stable,” “basic functionality,” not “fully optimized for cost”).

This makes your roadmap less of a fantasy and more of a risk-managed plan.

5. Keep Sessions Short and Focused

Hardware teams are often spread thin. Don’t turn Planning Poker into an all-day meeting.

Tactics:

Limit sessions to 45–60 minutes.
Prioritize the top 10–15 items that are most likely to be pulled next.
Pre-groom stories so they’re not vague “epics in disguise.”

If a story triggers 20 minutes of debate, that’s a sign it’s too big or too fuzzy. Create a spike or break it down.

6. Use Lightweight, Accessible Tools

Whether your team is on the factory floor, in the lab, or remote, make it easy to participate.

Use a simple digital Planning Poker tool so no one is influenced by others’ guesses.
Ensure it supports anonymous voting to reduce anchoring (especially when senior engineers are in the room).
If you’re already in Jira, use a tool that integrates with it so estimates flow directly into your backlog.

For example, tools like ScrumPoi let teams run free, anonymous Planning Poker sessions (and even retros) without signups, and sync estimates to Jira. The less friction, the more likely your hardware folks will actually use it.

So… Should Hardware Teams Use Planning Poker?

Yes—but only if you stop pretending hardware is just “slow software.”

Planning Poker works for hardware and physical products when you:

Redefine story points as effort + risk, not calendar time.
Include all relevant disciplines in the conversation.
Use disagreement in estimates as a trigger to uncover hidden work.
Separate engineering effort from supplier and manufacturing lead times.
Break down vague, monolithic “features” into estimable chunks.

If you want a silver bullet that predicts exact delivery dates for complex hardware with supply chain chaos and regulatory hurdles, Planning Poker won’t save you.

If you want a structured way to expose blind spots, align cross-functional teams, and avoid nasty surprises three months into a build—then yes, Planning Poker absolutely belongs in your hardware toolkit.