How to Effectively Use Jira for Hardware Development Projects

Jira, originally designed for software development teams, has become a widely used tool for agile project management. While its default setup caters to software teams using frameworks like Scrum or Kanban, hardware development projects have unique challenges that require a different approach to consider hard constraints, long lead times, and dependencies across mechanical, electrical, firmware, and software disciplines.

Despite these challenges, Jira can be an effective tool for hardware development when customized to meet the needs of hardware teams. By structuring workflows, aligning with key hardware development milestones, and leveraging Jira’s reporting and collaboration features, and integrations with electronics-focused development solutions such as Altium’s, teams can enhance visibility, streamline execution, and improve cross-functional alignment.

This article explores how hardware teams can effectively use basic Jira functionality while applying agile principles tailored for hardware projects.

Modifying Agile for Hardware Development – A Primer

Over the past few years, a variety of approaches have emerged to address agile hardware-related limitations, such as Hybrid Waterfall-Agile models, Scaled Agile Framework (SAFe) for hardware, Concurrent engineering practices, and the Modified Agile for Hardware Development (MAHD) Framework^®.

To provide some context to the recommendations for adapting Jira for hardware development, first, let’s summarize how these frameworks adapt agile methods overall to meet the needs of physical products. While each Agile hardware development framework provides a unique approach, this article draws primarily from the proven MAHD Framework to illustrate best practices. MAHD introduces concepts such as the On-Ramp (for project initiation), IPAC Iterations (for setting aligned strategic milestones), and customized Agile roles tailored to physical products. 

However, many of the Jira configurations discussed here—like tiered iterative cycles, structured backlogs, prototype tracking, evolving requirements, and milestone-based planning—are equally applicable to hybrid or SAFe-inspired teams.

Want a Deeper Dive Into MAHD Specifically? Download the Whitepaper: Modified Agile for Electronics Development: A Smarter Path to High-Value Solutions.

These customizations are essential for Agile hardware development success, which, in turn, drive the need for Jira adaptation.

Customizing Jira for Hardware Development

Most project management tools, including Jira, are very good at hierarchical work breakdown, but struggle when it comes to the complex information needs of physical solutions. That’s why it’s essential for teams to align on project management workflows from the start, from maintaining evolving artifacts like architecture and specification documents to defining how engineering change requests will be handled.

Here are important Jira customizations to consider in order to meet the needs of hardware and electronics teams.

Note: The following adaptations apply to the basic Jira application and do not assume access to Jira Align or other premium features such as Advanced Roadmaps. This setup can work fine for small to medium projects, but larger projects often require the use of additional levels of hierarchy and other premium features.

Create Tracks to Match Project Needs

Software projects can use a single backlog where all user stories and technical Tasks are prioritized in a single, linear sequence, but this approach does not work for hardware development. In hardware projects, Tasks across disciplines such as electronics, firmware, mechanical, and system engineering cannot be ranked against each other in one list. Instead, each discipline or subsystem requires its own backlog, referred to as a swim lane in the MAHD Framework or as a track or workstream in other frameworks.

As shown in the diagram, most projects include swim lanes for each discipline, such as electronics, firmware, and mechanical, and subsystems like power, IO, and CPU. In addition, system-level deliverables and milestones require dedicated swim lanes since they are tracked at the whole solution level. This structure ensures that work is properly managed within each area while maintaining alignment across the entire project.

Rethink Jira Structures to Match Hardware Development

Unlike software, hardware and electronics have a wider range of artifacts, dependencies, and development phases. Teams must consider how each element of the project will be managed in Jira, starting with establishing a basic hierarchy.

Work and Deliverable Hierarchy

One of the first steps to managing a coherent backlog in Jira is to determine your hierarchy and define terms. Jira’s default issue types (note that all work is considered an “issue” in Jira) types are Epics, Stories or Tasks, and Sub-Tasks. These are designed for software development, and though they are not ideal to capture the complexity of hardware projects, teams can usually make them work with a little creativity.

The basic structure that can work for most projects is:

1. Epic: Almost any deliverable, major work item, or milestone can be treated as an “Epic.” This allows teams to minimize levels and stay within Jira’s default issue hierarchy. An Epic typically spans multiple sprints or can even span multiple Iterations or the entire project.  Due to Jira’s inherent hierarchy limitations with its core product, specific work assignments such as “PCB layout,” “Firmware to support IO,” or “Create power enclosure in CAD” that take longer than a sprint are best managed as Tasks.
2. Tasks: Most work-based Epics are broken into Tasks. Tasks can be of any size, but if the Task is estimated to take longer than a sprint (typically two weeks) or requires coordination across swim lanes, it must be broken into Subtasks. For example, if a PCB layout (a Task) is estimated to take four weeks, the Task owner would create at least two Subtasks. One Subtask might describe the completion of a specific portion of the PCB layout, or if further breakdown isn’t practical or valuable, it can simply be defined as “PCB Layout – 50% Complete.” Note that Jira will often have “story” as the default hierarchical level under Epic, but changing this to “Task” is recommended to avoid confusion with software teams' usage of “user stories.”
3. Subtasks: These are the detailed work items estimated to require less than a sprint of effort.

Managing Iterations and Schedules

Hardware development requires structured planning, governance milestones, and schedules. Hardware Agile best practices address this challenge by enabling visibility of the whole project through multi-sprint milestone-based Iterations. These are called IPAC Iterations in the MAHD Framework (flexible durations of 1-to-6 sprints) and Program Increments in SAFe (fixed durations of 8-to-12 weeks). These help subsystems and discipline teams to align, test and demonstrate incremental capabilities to adhere to agile principles, as well as allow the team to communicate schedules.

The challenge is that Jira does not have intuitive capabilities to manage Iteration plans well. One approach some teams use is to leverage Jira Releases (also called Versions) to manage hardware Iterations. Unfortunately, Epics cannot directly be assigned to a Release (only Tasks and Subtasks can be). While this approach can work when only Tasks and Sub-tasks are associated with a Release, teams often find it difficult to manage and struggle to gain a clear, timeline-based view of the overall Iteration plan.

A better approach is to use Confluence, an Atlassian collaboration and documentation tool that integrates with Jira, to create and track Iterations plans.  This allows the team to see the whole plan in a simple spreadsheet or other view to track key milestones, deliverables, prototype strategies, and other items necessary for optimal planning and communication. You can create Epics and Tasks for each milestone or you also can create goal in Confluence, and then link them back to Jira for tracking and adding work items.

Managing Documents

Starting with the heavy documentation of hybrid approaches or the lighter MAHD On-ramp artifacts and through the entire project, it’s essential to track project documents. Again, basic Jira does not provide ideal facilities for this. However, teams can work around this by creating a swim lane for documentation and treating each document as a deliverable (Epic) with links to related content. Here, Confluence is also a helpful add-on to maintain all documents, from vision briefs to manufacturing plans. Similar to Iteration plans, any document created in Confluence can have links to the appropriate Epics in Jira and vice versa to maintain the digital traceability of each step. Another tip is to use Tasks under document Epics to break documents into sections for locking down decisions and enable traceability.

Project Execution - The Real Work

Jira is optimized for managing backlogs and project execution cycles. Once the team has aligned on the basic hierarchy and how they’ll manage multi-sprint Iterations, Jira becomes straightforward. Using the Jira Scrum Project setup, hardware teams can manage short execution cycles, typically called sprints, in a way that aligns wth both hardware and software development frameworks. However, whereas a software Product Owner typically maintains the entire backlog for a software team, Agile hardware teams require backlog swim lanes to be maintained by technical leaders who are knowledgeable about the work being planned. Each area of the backlog is updated after each Iteration planning meeting and then prioritized to guide sprint planning and Task execution. Teams will then follow a steady cadence of Iteration planning, backlog updates, sprint planning, and associated reviews until the project is complete.

Not Sure? Make It an Epic

After aligning on the core Jira setup, teams should consider how each project element will be managed. Staying with Jira’s simple default hierarchy, Epics can be used for a variety of purposes, including:

• Iteration Milestones: Iteration milestones, such as prototypes, integration goals, execution deliverables, and customer engagement activities, can be tracked as Epics. Since these typically span across disciplines, these will be linked to other Epics and Tasks in each Swim Lane to track work until each Iteration goal is satisfied.
• User Outcomes and Features: While software backlogs are filled with ‘user stories’ that equate directly to features and work items, hardware requires a way to track functional and non-functional outcomes at a more conceptual level. For example, the outcome, “As a satellite operator, I need to be alerted when signal parameters fall outside acceptable tolerances,” is defined as system-level User Stories in the MAHD Framework and Features or Capabilities in the SAFe Framework. These outcomes are typically satisfied by a range of product attributes and specifications, which require matrixed tracking – a challenge that most hierarchical tools, including Jira, do not handle well. However, by making these outcomes “Epics,” they can be linked to related product attribute work items to create the desired traceability.

These first two described uses of Epics are unique because they typically do not have a hierarchy of directly related Tasks in the backlog. Instead, they are tracked separately and linked to related Tasks across swim lanes to ensure alignment across the project.

Additional common deliverables that are good candidates for Jira Epics in hardware development projects include:

• Hardware Deliverable Epics: Major hardware deliverables such as PCB design, enclosure development, or field testing.
• System Deliverables: These include artifacts such as architecture or system specifications, Bills of Materials (BOMs), manufacturing plans, marketing plans, etc.
• Product Attributes: Epics can also be used to track the evolution of sections of technical specifications to enable traceability back to related user outcomes (Epics) and Tasks. For example, "Power system” might be an Epic that is a work-in-progress until the definition is frozen. It would get updated with new information and specifications as decisions are made until considered done.
• Test, Validation, Etc.: Major deliverables related to compliance testing, performance evaluation, supplier validation, preparing for manufacturing, and similar activities can also be treated as Epics.

Further Configure Jira to Your Project Needs

Once the team’s approach to the management of all project deliverables has been settled, the final step is to identify any unique workflows or communication needs of the project or team. Some further customizations to consider: 

• Clear Evolution Tracking: Tracking versions of designs, test plans, specifications, and other deliverables—and the decisions behind them—is essential but not always straightforward in Jira. Establish a clear method for communicating which elements are open, blocked, or complete, along with the rationale for key decisions. Custom tags, labels, and links to supporting documents can be helpful tools to support this visibility.
• Dependencies: Set up Custom Fields, Labels, or Tags or a common link approach to track dependencies between hardware and software teams as well as across swim lanes.
• Automate As Possible: Create automatic triggers to highlight new Tasks when prerequisite Tasks are marked complete or send reminders to act on long lead-time components to avoid supply chain bottlenecks.
• Progress Dashboards: Software teams often use burn-up or burn-down charts to report progress. Hardware teams must develop a simple, clear report to communicate progress based on past milestone successes and planned milestones. This should be automatically generated and tested to ensure it meets the needs of executives and other stakeholders. 
• Resource Utilization: Track and report workload distribution across teams. By leveraging Jira Filters, stakeholders can quickly access relevant data without navigating through detailed issue lists.

Integrating Jira with Hardware Product Development Tools

To bridge the gap between engineering and project tracking, many modern hardware development tools now offer integrations with Jira. These integrations allow teams to connect real-time design activities—such as schematic updates, PCB layout progress, or component decisions—directly to Jira issues, enhancing traceability and reducing manual task duplication. For example, Altium integrates with Jira, allowing engineers to link design tasks within their CAD environment to Jira Epics or Tasks, ensuring better alignment between technical work and project goals. This kind of integration helps teams maintain a consistent, up-to-date view of progress across disciplines and improves collaboration throughout the product development lifecycle.

Conclusion

While originally built for software, Jira can be a powerful tool for electronics development if properly modified to embrace Agile methods tailored for physical products. Whether managing prototypes, tracking dependencies, or aligning with software teams, Jira can serve as a central hub for hardware development success.