CUSTOMER STORY | HARDWARE + SOFTWARE
Anonymized Case Study:
How an IoT Manufacturer Coordinates Platform Sprints, Device Firmware, and Multi-Year Product Generations — All Inside Jira
This IoT release management case study is based on a recorded interview with a Head of Application Tools Support at a global connected-appliance manufacturer. Company and personal details are anonymized at the customer’s request.
About this case study
The team we interviewed runs a Smart Home division inside a global appliance manufacturer — platform and device teams building connected household products that combine embedded hardware, firmware, and cloud software. Their engineering setup, release structure, and the specific ways they use Release Management for Jira are reported as described in the interview. We have only removed details that identify the company.
Two teams, two cadences, one dependency chain
The platform team builds the foundation: the embedded OS, standardized computing modules, and shared sensor and actuator libraries that every product reuses. They deliver on two-week sprints inside an internal release train. A requirement should ship within four to six sprints. The cadence is fast and predictable.
The device teams own the final product — from requirements through to the firmware that ships on the physical device. Their cadence is slower by design. A new firmware build reaches UAT every two months, sometimes once a quarter. The reason is physical: everything has to be flashed onto real hardware, validated on real devices, and signed off through testing chains that do not collapse to nightly builds.
Above both, product generations span three to five years. A product line is planned at least two years out, anchored to international exhibitions, regulatory changes, and energy-efficiency standards. The current generation is already shipping. The next is due this year. The one after that is three to four years away.
The platform’s OS release train feeds all of these product programs at the same time. The same OS version becomes part of multiple product releases, at different content levels for each. Cross-project dependencies are not an edge case — they are the operating model.
What the team needed
Before adopting Release Management for Jira, the cross-program view lived in manually maintained dashboards, recurring status meetings, and slide decks updated by hand. It took effort to produce, effort to maintain, and was always slightly out of date by the time anyone looked at it.
What the team needed was not another tool alongside Jira. They needed a planning layer inside Jira that could hold all three cadences — platform sprints, device firmware drops, and multi-year product generations — in a single view, with real dependency tracking, without duplicating data across programs.
How they run IoT release management in Jira
Releases as wagons, packages as trains
The team models each delivery point as a release and groups them into packages that represent the business-level view: a product version, a generation milestone, a coordinated drop across hardware and software. The mental model maps directly to their release train structure.
Cross-project packages for shared platforms
The OS release train shows up inside every product package that consumes it — the same data, visible in multiple business contexts, maintained once. When the platform delivers a new version, every product program that depends on it sees the update without anyone copying status between boards.
Roadmap as the primary planning surface
Roughly 90% of daily usage happens in the roadmap view. Release managers lay out the next two years, anchor milestones to immovable dates (trade shows, regulatory deadlines, generation launches), and fit development into the remaining windows. Dependencies between platform and product programs are visible in the same view. The plan is no longer a slide deck — it is something teams actually plan against.
Burnup charts for short-term predictability
Managers use burnup charts to check whether a release is on track without requesting a written status update. Projected release dates inside the burnups answer the sprint-level question: can this feature still make the upcoming delivery, or does it slip to the next wagon?
Confluence dashboards for leadership
Senior leadership, program sponsors, and cross-functional reviewers who do not live in Jira get release dashboards embedded directly into Confluence pages. Same format across every product. Leadership reads release status next to the explanatory context they expect, in a shape that stays consistent whether they are looking at one program or fifteen.
What changed after adoption
The status picture assembles itself
Cross-team, cross-product status that previously required manual dashboards, recurring meetings, and hand-updated decks now exists by default. Nobody has to build the view before the next review.
Planning starts from the release, not the sprint
The team shifted from time-and-effort planning to content-driven release planning. The question is no longer “what fits in this sprint?” but “what does this release need to contain?” Sprints stay sprints, and the multi-year generation roadmap keeps its own horizon — but release packages give the two scales a place to meet, inside Jira.
Program-level confidence in complex structures
For anyone in a cross-team or company-level role, Release Management for Jira is the one place where the full structure is visible end to end. The consistent feedback is confidence — confidence in dependencies that would otherwise live in someone’s head or in a spreadsheet that goes stale within a week.
“It gives us confidence in complex structures. For anyone in a cross-team or company-level role, it is the only tool in our stack that provides that bird’s-eye view automatically.”
— Head of Application Tools Support
What’s next
The team is expanding Release Management for Jira to more programs across the organization. Each program added makes the cross-project view more complete for everyone already using it.
They are also tracking the AI direction closely. The clearest near-term value: conversational access to release data — top blockers, scope summaries, planning queries answered in plain language instead of assembled by hand. As Atlassian Rovo and agent capabilities mature, the team expects to cut a meaningful share of routine effort from the release planning workflow.
If your teams ship connected products and struggle to hold platform, firmware, and product roadmaps in one view — this is the problem Release Management for Jira was built for.