Splitting PLM User Stories with SPIDR methodology
In Agile development, one of the key practices to increase efficiency, flexibility, and adaptability is the art of splitting user stories. However, splitting user stories is not just about breaking them down into smaller tasks – it’s about creating a set of smaller, valuable, and actionable stories that can be delivered incrementally. This allows teams to focus on high-priority features, gather feedback quickly, and adjust as needed.
The most famous and effective method in Agile Development to split tickets is SPIDR method, developed by Mike Cohn(source Google). It provides a structured approach for splitting user stories. SPIDR is an acronym that stands for Spike, Path, Interface, Data, and Rules.
Well as most of you might know if you are implementing Teamcenter for your customer or within your organization, it is very challenging to cover all of the scope in one single go. At the same time, pushing the new features or enhancements immediately to Productive system is the need of project. Hence here comes the situation to split the functionality in small tickets in order to provide incremental enhancement to get going.
In this article, we'll explore how to apply SPIDR to the context of Product Lifecycle Management (Teamcenter). Here I would take an example, and try to apply the spliting methodology on the same.
Example :
Target :
- “As a product manager, I want to be able to receive data in PLM from legacy system , so that I can manage revisions and approvals more effectively.”
What is known
- All the technical details are unclear.
- Data model changes are not yet identified.
- Few features are known, such as data import and ability to work on the imported data.
Lets dive in to the methodology and try to split the feature of this integration in to multiple tickets.
Spike: When Uncertainty Exists
A S in SPIDR refers to Spike which intern refers to a user story or task focused on research or experimentation to reduce uncertainty. This is particularly useful in PLM systems, where new technologies, complex integration scenarios, and compliance requirements can introduce, are unknowns.How to apply Spike in PLM:
- Investigate different integrations or product data management (PDM) tools that align with the PLM system.
- Research possible data point matching mechanism between the two different systems.
- Explore data security protocols before deciding on an architecture for a new PLM feature.
- And finally take one or more POC tickets to investigate best set of tool and technology to be used and metigate the uncertainty.
Path: When There Are Multiple Flows or Routes
In PLM systems, there can often be different paths for achieving the same goal. A Path split is useful when a feature or functionality can be achieved by multiple routes, and each route offers different challenges or complexities.In the current example, the interface can be triggered to import the data in Teamcenter, in various ways and for multiple scenarios. Such as through a manual process or automated workflow. These paths might require different implementation or data validation processes.
How to apply Path in PLM:
- Split a user story into multiple user flows or processes (initial vs. change case transfers, different user access roles, etc.).
- Further split the user story into import sucess path and import failure paths.
- Divide the tasks for handling product data revisions across different product lines that may require distinct management practices.
- Develop separate stories for designing and implementing APIs or data transfer protocols between PLM and external systems.
Interface: When Different Entities Interact
The Interface approach focuses on splitting stories based on how the product interacts with other systems, external applications, or users. Teamcenter system is quiet commonly used in Rich Client or AWC.And Interface appaoch also deals with creating simple versions and adding the complexity step by step.
So in the current example: The user story can be splitted based on what we would show in rich client and what need to be done in AWC.
How to apply Interface in PLM:
- Split out user stories based on the different interfaces the type of the client interface used.
- Split the user story into mutliple based on various actions are taken after import is done. Take a ticket for just basic data creation, another for Assigning status, another for transfering the data other other system etc.
- Focus on the user interface (UI) for each group of users interacting with the PLM system, considering product managers, engineers, or supply chain managers.
Data: When There’s a Large Amount of Data
The Data split occurs when a user story can be divided based on different subsets or types of data. In PLM systems, managing large volumes of product data—such as designs, specifications, bill of materials (BOMs), and Bil of Process —can be overwhelming.In the current example: A user story that involves importing product specifications into a PLM system can be split based on the different types of product data that need to be imported, such as materials, drawings, and design documents, BOP etc.
How to apply Data in PLM:
- Split stories based on the types of product data (e.g., material data, design documents, BOMs, etc.) that need to be integrated into the system.
- Focus on how to handle different stages of the product lifecycle (e.g., initial design data vs. production data).
- Break out stories that involve cleaning, validating, or transforming large datasets during the import process to make them suitable for use in the PLM system.
Rules: When There Are Business Rules Involved
The Rules split involves breaking stories down based on business or regulatory rules. In the PLM domain, companies must follow strict rules about product quality, safety, compliance, and versioning. These rules can often be complex and need to be reflected in the system’s features.In the current example: A user story about managing product revisions in a PLM system can be split by the various rules related to version control, approval processes, and compliance requirements specific to a product's market (e.g., medical devices, automotive parts, etc.).
How to apply Rules in PLM:
- Break out stories that focus on implementing different business rules or regulatory standards (e.g., ISO compliance, FDA approval requirements).
- Split in to mutliple stories to cover data validations and sanity checks.
- Split a user story about product release into smaller stories focusing on different release phases or requirements (e.g., design approval, testing, production release).
Comments
Post a Comment