Once I have captured the core business events that create the required data as outlined in my previous post:
I move onto the seventh area, the Feature Stories.
In the Feature Stories area I capture the key features which need to be incorporated into the Information Product.
I want to understand any new or unique features that are required. This helps us identify whether these features have already been built or if I need to build them as part of delivering this particular Information Product.
For the Feature Stories I use an iteration of the agile user story format:
For a [persona or audience]
I want [what feature do they want]
Feature stories are a potent tool for capturing the stakeholders’ needs in an understandable and actionable way. They ensure that the Information Product is designed and built to meet its users’ actual needs.
We are seeking the first three to five features which spring to mind for the stakeholders.
They might have more, that’s fine, they can keep adding to the Canvas. Once the stakeholder pauses to think more deeply, we move to the next area in the Canvas.
When writing feature stories, we focus on user’s needs, not the technical implementation. We aim to capture what the user wants to do, not the how. The technical implementation is determined later, during the delivery process.
If you are using an off-the-shelf last-mile tool like Looker Studio and the requested features are available in that tool, there is no need to add them hereÂ
We aim to identify a few key features we know the Agile Data Team will need to build, particularly those we recognise are high effort or high risk to deliver.