How to define an Increment in "Hardware" Scrum

Challenges in "Hardware" Scrum

Challenges in “Hardware” Scrum

Build and test time in hardware products often can’t be reduced to the timeframes we know from software development, even with a certain amount of automation. For sure, openness towards incremental development can reduce cycle time for hardware businesses, but in most cases the “real” Definition of Done — including expensive tests (e.g., automotive winter testing) and certifications — can’t be fulfilled in every Sprint.

So we would either have to expand a Sprint to several months, or we would have to work with different types of Increments that allow shorter development cycle time. With the Scrum Guide in mind, let’s take the second approach.

Model-Based Increments

Whereas in software we normally have one Increment — which is the “real” product — in hardware we often work with models of the product.

What is a model? A common definition would be: A model is an abstraction of reality for a certain purpose. In Hardware Scrum, a model-based Increment could be a physical mock-up to get feedback about the design or usability. Another model could be a simulation to get feedback about mechanical forces, heat distribution, etc.

We can identify different types of Increments:

• Product (the product itself, as it is done in software development)
• Physical model (e.g. prototypes, mock-ups)
• Informal digital model (e.g. AI images, bitmap images etc.)
• Formal digital model (e.g. simulations, digital twins etc.)
• non-product-related models (e.g. in research and science)

Of course, each Increment type has its own Definition of Done. The goal is to pick a handful of useful Increment types and order them by decreasing level of abstraction. Let’s provide two examples.

For a mechanical housing, the Increments could be:

1. A 3D model in a simulation
2. The housing 3D-printed out of plastics
3. The housing 3D-printed out of aluminum
4. The housing molded out of aluminum (the “real” product)

For an ECU (electronic control unit) the Increments could be:

1. The control algorithm simulated in Matlab-Simulink
2. The generated code running on an eval board
3. The generated code running on the real PCB
4. The PCB and the software in the housing, ready for environmental tests (the “real” product)

This approach shows, that in contrast to the software, where we are used to introduce every feature in the final quality, in Hardware Scrum model-based increments can be used to adjust the maturity of an increment and thus shorten cycle time (see illustration 1).

Illustration 1: Maturity vs Functionality

The model-based approach should not lead to arbitrariness, the model type should be part of the Sprint Goal. Depending on the environment, it could be useful to have a maturity roadmap which is synchronized to external milestones.

Want to learn more?

Our next Blog-Topic will be: "How to reduce cycle time in "Hardware" Scrum?"

Our Webcast regarding "Hardware" Scrum will be on the 16th April 2026 here at Scrum.org

Additional Sources (German Language):

https://www.scrum-events.de/training-details/certified-agile-systems-engineer

https://joachim-pfeffer.com/case/