Scrum has been widely adopted in software development, but applying it to hardware engineering raises questions about which Scrum practices translate successfully and which require adaptation. This article draws on a Scrum transformation I led at a biotechnology company developing a new mass spectrometer. The engagement provided an opportunity to test a conclusion I had reached during eighteen months of prior research: while the Scrum framework itself translates well to hardware development, many software-oriented implementation practices do not.
The differences between hardware and software development are not merely procedural, but structural. They change the way engineering organizations think about ownership, decomposition, and planning. Some of those differences concerned the role of the Product Owner and why the software model did not translate directly to a hardware engineering organization.
Product Owner as Team Member
The Product Owner for the project was a physicist who also participated in the development work as a part-time member of the Scrum team. What was unusual was that the Product Owner not only provided product leadership, but also functioned as a part-time member of the Scrum team. (I have since observed the same pattern at a number of other hardware-development organizations as well.)
Unlike software Product Owners, who often come from product management or marketing backgrounds, this Product Owner possessed deep technical expertise. To be effective, the Product Owner required such detailed knowledge of the product’s internals that contributing directly to engineering work was not merely possible, it was necessary.
One consequence of this pattern is that a hardware organization may require more Product Owners than a similarly sized software organization. Because a hardware Product Owner often contributes directly to engineering work, that person typically has the capacity to support only a single Scrum team rather than two or three.
Effective Product Ownership in hardware-development environments often requires deep technical expertise.
Component-Based Decomposition
Software teams decompose product scope by user experience. When facing the need to implement a new software product, they begin by listing the user experiences. When facilitating this exercise with teams, I would ask them to list the user experiences first and then ask them to identify the infrastructural elements they would need to support the user experiences. This approach produced a good first pass at defining the work to be done to develop the product.
In software development, the result is typically a layered architecture, where the visible part sits on top of a set of infrastructural layers, and the work to implement a particular User Story often involves doing work at multiple levels of a “vertical slice” through that technology stack.
At this company, the team members could certainly identify user experiences for the mass spectrometer, but they did not think in terms of user experiences when decomposing the scope of the product.
I observed this when I asked some fundamental questions at the start of Release planning, namely, “How do you think about the major pieces of this device?” and “How do you organize your understanding of the design of the product you want to build?”
What emerged was quite different from the software model. Instead of focusing on user experiences, they focused on the product’s physical components and subsystems. User experience played only a secondary role in the discussion. (They were not indifferent to user experience; it was simply not where the bulk of the conversation went.)
As an experiment, I tried steering the discussion back toward user-facing capabilities. While the team was happy to talk about them, the discussion was not fruitful for scope decomposition, and they quickly re-focused on component-oriented decomposition. Their reasoning was clearly grounded in the physical architecture of the product, so I allowed the discussion to proceed naturally.
Hardware teams often think about product scope in terms of physical architecture rather than user experience.
Technical Stories versus User Stories
The next difference also showed up in preparation for Release planning when the team began writing Epics and Stories for use in planning. (Note that Epics and Stories have the same Title-Narrative-Acceptance Criteria format. They differ only in that an Epic entails more work than the ceiling for a Story and must be decomposed into Stories before their use in Sprint planning.)
In my work, I have found it useful to distinguish between two kinds of Stories: User Stories and Technical Stories, and likewise two kinds of Epics. A User Story is commonly understood to be a description of a user experience to be implemented in the product. Where I differ from common practice is that I define a second category of Story that describes a technical deliverable rather than a user experience. A Technical Story uses the same structure as a User Story but describes a technical deliverable rather than a user interaction and thus omits the user role.
I have seen “Story purists” argue that User Stories should be the only type of Story used, and that infrastructural work should be incorporated in User Story work as part of a vertical slice through the technology stack of the product. In my experience, though, there are often deliverables for which that simply is not practical, and rather than try to force-fit such cases into User Stories, I suggest that teams write Technical Stories for those deliverables.
An architecture document, for example, is not logically part of a User Story.
On this project, the scope decomposition of the product led naturally to Stories that were about components, assemblies, and subsystems, not user experiences. This meant that all Stories were Technical Stories, and User Stories were simply not used at all. This again is quite different from the usual pattern for software development.
Hardware development frequently requires Technical Stories to become the primary specifications artifact for the team’s deliverables.
Distributed Story Writing
The usual pattern I’d been accustomed to seeing was that the Product Owner wrote User Stories (the majority of the Stories) while team members wrote occasional Technical Stories (the minority). When preparing for Release planning meetings, team members might help out the Product Owner by drafting “User Epics,” but the onus was on the Product Owner to approve the writing.
The pattern was different in this transformation. Since the Product Owner was also a team member, and only Technical Stories and Epics were going to be written for use in Release planning, the work of writing these specifications was distributed across the Product Owner and Team members. This distribution had the nice effect of not burdening the Product Owner with the bulk of the work, which proceeded at a good pace.
Story-writing responsibility becomes naturally distributed when technical specialists possess much of the knowledge needed to define the work.
Conclusion
These observations are not isolated adaptations. They are interconnected consequences of developing physical products rather than software. They also suggest that simply transplanting software Scrum practices into hardware development is unlikely to produce optimal results.
The Scrum framework itself translates well to hardware environments, but key Scrum implementation conventions—particularly the Product Owner role, backlog decomposition, and Story authorship—must reflect the realities of engineering physical products rather than software systems.
These adaptations reflect the fact that in hardware development much of the knowledge needed to define and prioritize the work resides with the engineering specialists themselves rather than solely with the Product Owner. Recognizing these structural differences allows Scrum to be adapted in ways that preserve its strengths while better reflecting the realities of hardware engineering.
This article summarizes several of the key observations from a larger Scrum implementation in a hardware development organization. A more detailed case study describing the implementation, the organizational context, and additional lessons learned is available here.
