The term story has become established in the Agile world. They describe results that are available at the end of a sprint. It has been shown that even outside the software world, in mechatronics and other areas, the precision in describing the results of a sprint benefits greatly if they are written in story format. Most digital tools for Agile Boards also use the term and provide a predefined work item type “Story“, which we can easily adopt in mechatronics as well.

Examples of stories in mechatronics:

• Purchasing needs the drawings of the enclosure in order to be able to request the tools from the suppliers.
• The layout designers need the circuit diagrams revised with the findings from the EMC tests in order to be able to make person B of the PCB ready for ordering.
• The POT needs the results of the system tests in order to decide on the delivery of the first beta test units.

A story does not always deliver a function that can be perceived by customers. In mechatronics, it is even rather rare. It can have a wide variety of results:

• The initiation of a supply chain
• Designing a hardware component
• Providing information
• Ability to make a decision, e.g. architectural decisions
• Documentation, e.g. for approvalsReduction of risk

…Whereby all of this actually also applies to software projects. There are also these types of stories.

Writing good stories takes practice. Agile coaches will help the POT with this. Good stories negotiated with the team add up to a very clear mission for the team for the next sprint.

A sequence of stories that belong to a feature describe the way to get to the desired feature in the stage.

• It conveys the meaning
• Has clear completion criteria
• Can be estimated and fits into a sprint
• Stories in a sprint have similar sizes
• Stories in a sprint are as independent as possible so that not all stories “fall” if one story is blocked in the sprint.