The short answer
EVT, DVT and PVT are the three validation builds of a hardware product: engineering validation test, design validation test and production validation test. In Jira you plan each build as a milestone with written gate criteria, link the electronics, firmware, mechanical and software work that must be ready for it, and keep test results tied to the build revision they ran on. Then anyone can see how close a gate is without a meeting.
What are EVT, DVT and PVT?
Hardware products move through validation builds before mass production. The names are industry convention, from consumer electronics, rather than a standard, so details vary by company. The question each build answers doesn’t:
| Build | Question it answers | Typical evidence |
|---|---|---|
| EVT, engineering validation test | Does the production-intent design work? | Bring-up, functional tests, first firmware, pre-compliance scans |
| DVT, design validation test | Does the final design meet all its requirements? | Full verification, environmental tests, formal certification |
| PVT, production validation test | Can the factory build it at volume and quality? | Yield, process checks, production test results |
Before EVT come engineering prototypes, often separate looks-like and works-like builds. After PVT comes mass production and the ramp. If you’ve searched “DVT” and found medical pages, that’s a different meaning; here it’s design validation test.
What is a gate between builds?
A gate is the decision to move on, move on with conditions, or stop. Robert Cooper’s Stage-Gate model names four outcomes: Go, Kill, Hold and Recycle. Either way, a gate commits money: tooling, a certification lab slot, a production order.
The problem is rarely the builds themselves. It’s that electronics, firmware, mechanical and software each plan in their own tool, and the gate decision is made in a meeting from slides that were out of date when they were made.
How do you model builds and gates in Jira?
- One milestone per build. EVT, DVT and PVT become versions or milestone work items with target dates, on the same timeline as the sprints.
- Gate criteria written before the stage starts. Each gate gets its criteria as a checklist or linked work items: “all DVT tests passed”, “EMC pre-scan done”, “no open blockers on the power board”. Agreed early, not in the gate meeting.
- Work linked to the build it’s needed for. Firmware features, board revisions, mechanical changes and test cases link to the build milestone. A late item shows its build at risk.
- Long-lead parts next to the build. Each part carries its committed date and an order-by date, linked with “Blocks” to the build. See tracking long-lead parts next to sprints.
- Test results tied to the build revision. A pass on Rev B boards says nothing about Rev C. Keep the revision on the result.
- Gate decisions recorded. Go, go with conditions, or stop, with the reasons and the open issues carried forward, each with an owner.
How do firmware sprints line up with builds?
Keep firmware and software in short sprints, and let each build set a “must be in” date. Before planning a sprint, the team looks at which work is linked to the next build. If something can’t make it, the build or the scope moves on purpose, not by surprise at integration.
If you run MAHD, each IPAC iteration ends in an integrated result that feeds evidence into the next gate. The MAHD guide shows how the two fit.
How do you see gate readiness without a meeting?
A dashboard per build shows the gate criteria and their status, the linked work still open, the test results so far and the parts still missing. When the gate review happens, it’s a decision, not a status hunt.
Across several spaces, the basic Jira timeline won’t show the dependencies, because it only draws “Blocks” links within one space. Jira Plans (Premium and Enterprise) does, and so does Gatecast for Jira, our app, which shows builds and gates on one timeline.
Where do teams usually start?
Start with the next build, not the whole program. Write its gate criteria, link the work that must be ready, and run one gate this way. That’s the Blueprint stage of the Product Ops Flywheel: one real flow, traced live, before rolling it out.
The Hardware Stage-Gate Readiness Check: 18 questions, about six minutes, your score right away.
Questions people ask
What's the difference between EVT, DVT and PVT?
EVT (engineering validation test) checks that a production-intent design meets its functional requirements, usually on the first boards and enclosures built by the manufacturer. DVT (design validation test) checks that the final design meets all its requirements, including environmental and cosmetic ones; formal certification usually runs on DVT units. PVT (production validation test) checks that the factory can build it at volume and quality, with no more design changes.
What comes before EVT?
Engineering prototypes, often separate looks-like and works-like builds, made without production tooling. EVT is usually the first build that combines both in the final form factor, with production-intent parts and processes.
When does certification testing happen?
Pre-compliance scans (EMC, radio) often start around EVT. Formal certification is usually run on DVT units, and sometimes on PVT units when the design or process is still changing. Plan the lab slot as a dated dependency of the build it needs.
Can firmware run in sprints while hardware runs in builds?
Yes, and it usually should. Firmware and software work in short sprints; each build sets the date by which certain sprint work must be in. Link that work to the build milestone so a slip shows on both sides the same day.
Do we need Jira Plans for this?
For one team in one space, a timeline and fix versions are often enough, but the basic timeline only shows "Blocks" dependencies within a single space. Once electronics, firmware, mechanical and software plan in separate spaces, Jira Plans (in Premium and Enterprise) or an app shows dependencies and dates across all of them.