Thermo Fisher Scientific: Lesson #5 – Say Good-Bye to User Stories?
One of the more surprising discoveries during the Thermo Fisher Scientific engagement involved the role of User Stories.
In software development, User Stories are one of the primary mechanisms used to describe work. A typical User Story describes some aspect of the user experience and provides a way for the Scrum Team to discuss, estimate, prioritize, and deliver functionality.
This approach works well because software products tend to evolve by adding user-facing capabilities over time. Teams frequently implement functionality that cuts across multiple layers of the technology stack, yet ultimately delivers a coherent experience to the user.
The Thermo Fisher project looked very different.
As discussed in the previous post, the product evolved primarily through the creation of components and subsystems. The team's work focused on designing, building, testing, and integrating the physical elements of the device rather than implementing end-user functionality.
As a result, traditional User Stories quickly lost much of their usefulness.
The deliverables being produced during a Sprint were typically not user experiences. They were circuit designs, subsystem interfaces, prototype components, test fixtures, and other engineering artifacts necessary to build the final product.
To describe these deliverables, I began using a term that I coined years earlier: Technical Stories.
A Technical Story describes a deliverable that must be produced but does not correspond directly to a user experience. Unlike a User Story, it typically does not contain a user role or user-facing objective. Instead, it focuses on the engineering outcome that must be achieved.
This distinction proved important.
The behavior of the mass spectrometer was certainly important. The team cared deeply about how the final product would function and how customers would use it. However, those concerns were represented primarily in the product's higher-level requirements and architectural decisions.
At the Sprint level, the team's work was dominated by the creation and refinement of individual components and subsystems.
The completed product would ultimately deliver a coherent user experience, but that experience emerged from the successful integration of many separate engineering deliverables.
This led to another important lesson from the project.
Lesson #5: User Stories play a much smaller role in hardware development than they do in software development. Technical Stories become the dominant mechanism for describing Sprint-level work.
This observation has significant implications for backlog management, estimation, planning, and stakeholder expectations. Teams that attempt to force all hardware work into traditional User Story formats often find themselves fighting against the natural structure of the work.
In the next post, I will discuss another challenge that emerged from this reality: why the team initially struggled to write Stories at all.
For those interested in the full case study, the complete Thermo Fisher Scientific story is available on my website at https://kevinthompsonphd.com/storage/papers/LessonsLearned-AgileHardware-v6.pdf.
