14
• Testing software commonly requires developing thousands of test cases, with perhaps a few to
a few tens of new test cases being developed per month over the life of the product. Hardware
testing involves far fewer tests, but more specialized and expensive equipment.
• Software testing is commonly done by, or defined by, specialized Quality Assurance (QA)
engineers, while hardware testing is commonly done by the engineers who are creating the
product.
• Hardware must be designed and tested to work over a range of time (aging) and environmental
conditions, which is not the case for software.
• Hardware development incorporates four parallel, synchronized projects: 1) The detailed design
of the manufacturable product; 2) the manufacturing process and tooling; 3) the test and
inspection process and equipment; and 4) the supply chain for purchased parts. In software
development, the detailed design is the product, and production deployment consists of moving
the product into a context where it can be used.
• The cost of development for software products is relatively flat over time (aside from the usual
hiring and attrition). However, the cost of hardware development rises rapidly towards the end of
the development cycle for hardware products.
• Due to many of the above factors, it is possible to make major changes in direction for a planned
software-product upgrade in mid-development, without massive disruption and waste. Attempts
to make such changes in hardware development come at a much higher cost, in terms of sunk
costs wasted, and shipping schedules postponed. As a result, major changes must either be
deferred to a future product upgrade, or are done when an assessment is made that the impact
is justified by the magnitude of the benefits.
5 Scrum-Process Customizations for Hardware Development
We had no particular expectation that a Scrum process would be applicable to hardware development,
but our research showed that Scrum is indeed relevant. There are, however, important nuances that
differ from the software-development world. This section clarifies how a Scrum process for hardware
development differs from the norm for Scrum in software development.
Story Types
Products (whether software or hardware) have many testable components, which are developed in some
sequence. Agile processes encourage division of product scope into fine-grained pieces, each of which
can be developed and validated in a few days’ time. The small size of these deliverables reduces
schedule risk, and increases flexibility for changing the scope or plan of the product’s development.
In the Scrum process specifically, the requirements for each small deliverable are provided in a
standard “Story” format (see Section 0). The boundaries of Stories are “hard,” meaning that the intent is
for a Team to start and complete all work to implement and validate a Story within the bounds of the
same Sprint. While exceptions will occasionally occur due to unforeseen issues, we will never plan to
start work on a Story in a Sprint that we know cannot be completed in the same Sprint.