Once I have captured the wills and the wont’s that capture an early idea for the scope of of this Information Product as outlined in my previous post:
I move onto the ninth area, the Information Product Name.
In this area I capture a unique name for the Information Product.
This name will commonly be used to refer to the Information Product in discussions with stakeholders and the Agile Data Team.
The name should, at a glance, reflect the Information Product’s purpose and content.
The name could be based on the main business question the Information Product aims to answer, the core business processes it supports, the key data it encapsulates, or the main action or outcome it supports.
The name serves as a shorthand reference for the Information Product, enhancing understanding and recall among everyone involved in its delivery and ongoing use.
Try to keep the name short but descriptive. When managing a backlog with hundreds of Information Products, a concise but descriptive name proves incredibly helpful.
Naming should consider your organisation’s culture and conventions. Some Agile Data Teams have found a prefixed numbering system (i.e., 001, 002, etc.) useful for identification, while others prefer more unique names.
After agreeing a name, ensure it is consistently used in all communications about the Information Product. This helps ensure that everyone is clear about what you’re referring to and reduces risk of confusion.