Stage gates for hardware + software,on one plan in Jira.
Your software teams have never been more agile, and the product has never been later. We put electronics, firmware, mechanical and software on one plan in Jira, run with Modified Agile for Hardware Development: builds, gates and long-lead parts where everyone can see them, so a slip shows up the day it happens.
What is a stage gate process?
A stage gate process splits product development into stages separated by gates. At each gate, the team checks agreed criteria before money and time go into the next stage. In hardware, the stages are usually builds: EVT (engineering validation), DVT (design validation) and PVT (production validation). In Jira, each gate becomes a milestone with the work, parts and tests behind it.
Monday, 9:30
Did you ever find out at the Monday sync that the DVT boards are three weeks late, after firmware had planned around them for a month?
Nobody hid it. The supplier emailed purchasing on Thursday. Purchasing updated the spreadsheet. The spreadsheet isn’t in Jira. Firmware lives in Jira.
So for four days, eight firmware engineers kept building for a board that wasn’t coming. And on Monday, at 9:30, in a meeting that was supposed to take 90 minutes and took two hours, you rebuilt the plan. Again.
Then Thursday comes. The exec meeting. Someone asks the question you’ve started dreading: “Are we still on for the launch window?”
You say “it’s tight”. What you mean is: I can’t tell you, because the answer is spread across four tools and one person’s head.
DVT boards: +3 weeks
| BLE bring-up | Done |
| OTA update | Waiting for DVT |
| Power tests | Waiting for DVT |
What’s actually going on
Your teams aren’t failing. Your plan is.
Software runs two-week sprints. Hardware runs on builds and supplier dates. Mechanical runs on tooling. Each one is doing its job well, on its own map. Nobody owns the place where the maps meet, and that’s exactly where your launch dates go to die.
And no, the answer isn’t SAFe. You tried that. It became meetings.
One plan your teams will actually keep
Now picture next Monday.
There’s no 90-minute sync, because the plan is already on the screen. One plan: the EVT, DVT and PVT builds as milestones, each with gate criteria written before the stage started. The firmware sprints that feed each build. The long-lead parts, each with its order-by date, linked to the build that needs them.
When the supplier moves a date, the build it blocks shows the risk the same day, in Jira, where firmware already lives. Nobody has to hear about it at a meeting.
On Thursday someone asks about the launch window. You open one view and answer with a date, and with the two things that could move it.
We set this up in the Jira you already have, around the way hardware is actually built. Software keeps its sprints. Hardware keeps its gates. Nobody has to pretend a board revision fits in two weeks.
EVT
DVT
PVT
Firmware
MCU-32
Order MCU-32 by 11 Nov
What we set up in Jira
One plan across electronics, firmware, mechanical and software. Each build (EVT, DVT, PVT) a milestone with written gate criteria and recorded decisions. Long-lead parts with supplier dates next to the sprints that depend on them. Test results tied to the build revision they ran on. And a view your leadership can read without calling a meeting.
FB-207Field issueIn placeDEC-044Design decisionIn placeREQ-031RequirementIn placeEVT-3EVT buildIn placeDVT-2DVT testPartlyPVT-1PVT releaseGapGatecast: milestones and stage gates on one timeline
Our own app for Jira shows whether each build will make its date, what it waits on and which parts arrive late.
What is Modified Agile for Hardware Development (MAHD)?
Modified Agile for Hardware Development, a framework from Gary Hinkle and Dorian Simpson at Auxilium, keeps sprint work close to Scrum and groups sprints into IPAC iterations, typically 2 to 8 weeks long. Each iteration is planned around four activities: Integration, Prototyping, Alignment and Customer Engagement. An iteration plan sets when designs freeze, and work is accepted at both sprint and iteration level. We set it up in Jira so firmware and software sprints, hardware builds and long-lead parts sit on one plan.
AcceptanceIn review
When hardware teams usually call us
- A build slippedThe launch window is at risk and nobody can say with confidence whether the next build makes its date.
- A new product line or board revision startsThe right moment to set up one plan across disciplines, before the first build locks in old habits.
- The board asks about predictabilityAn investor or board question on delivery dates, often before a funding round, and the answer lives in several spreadsheets.
- A part or a supplier exposes the planA component shortage or a supplier delay shows how much of the plan depended on dates nobody tracked.
Not another agile roll-out
We’ve seen agile fail in hardware when software ignored lead times, and frameworks turn into meetings. We don’t replace your PLM, sell you certification courses or ask hardware engineers to pretend a board revision fits in two weeks. We plan around builds, parts and gates, and let software keep its sprints.
12 ceremonies · 3 certifications
BuildsEVT · DVT · PVT
PartsOrder-by dates
GatesDecisions
How we work with hardware teams.
The same five stages, shaped around your builds and gates.
Flywheel
Your current plan mapped across disciplines; gates and late parts ranked.
One plan with build stages, gate criteria and MAHD cadences; one build traced live.
Jira set up with milestones, parts and supplier dates; your team trained.
Gatecast, automation and gate reports once the flow is in use.
A review before each build gate.
- Then back to Teardown before the next build.
A first engagement usually starts with Teardown, a fixed-scope look at how your work flows today. Scope agreed on the review call.
Find out where your plan breaks, in six minutes
Before you change anything, find out where your plan actually breaks. That takes six minutes, not a workshop.
The Hardware Stage-Gate Readiness Check asks 18 questions about how your teams plan today. Your score shows right away, area by area, with no email needed to see it.
You’ll find out:
- whether your disciplines share one plan, or four plans that meet at the Monday sync;
- how early a late part would reach the people who depend on it, and why it’s usually later than you think;
- whether your EVT, DVT and PVT gates are decisions or debates;
- the one view your leadership is missing when they ask about the launch window.
Take the Hardware Stage‑Gate Readiness Check
P.S. We don’t replace your PLM, sell certification courses or roll out a framework from the top. We plan around your builds, parts and gates, and leave your engineers to do what they’re good at.
58/100
- One planPartly
- Long-lead partsGap
- EVT, DVT and PVT gatesPartly
- Leadership viewIn place
Questions hardware teams ask
How do I run EVT, DVT and PVT builds in Jira?
Make each build a milestone, link the work for it through fix versions across your team spaces, and agree its gate criteria up front. Add the parts each build needs with their lead times, so a late part shows up against the build before the build day.
How can hardware teams work agile with long-lead parts?
Keep sprints for the work that can move quickly, and track long-lead parts next to the sprints that depend on them, with order-by dates worked back from the build. That way the team plans around parts instead of being surprised by them.
How do I plan electronics, firmware and mechanical work in one Jira plan?
Use one plan with a lane per discipline, shared build milestones and “is blocked by” links between lanes. Each team keeps its own board, while the plan shows how the disciplines depend on each other. Across several spaces, that view needs Jira Plans (Premium or Enterprise) or an app.
Find out where your plan breaks.
A free 45-minute review call with Ewa. We look at how your builds, parts and sprints connect today, and what to fix first.