The Road to MVP and Beyond
"The road to MVP and beyond "
The Challenge: Getting to MVP(minimum viable product) or ETP( earliest testable product) and beyond in an informed, efficient and decisive way. Making sure everyone is in alignment from a customer/client, product and engineering perspective from the outset is the best chance at reducing time to market while meeting stakeholder needs.
Our Approach: By establishing our own storyboard matrix we have invited more collaboration into the development process. While we are still ironing out the kinks, this way of working has streamlined our process and provided an archival view for future development. It may not be the definitive way, but it works for us, and will continue to evolve over time.
Core steps
1. Adding Comments from Different Perspectives
One of the first steps in the workflow is to gather comments from various stakeholders, including client perspective, product, and engineering. Each perspective is valuable and helps shape a well-rounded user story. During this phase, we:
- Collect comments on user stories, focusing on client needs and requirements
- Challenge the story and acceptance criteria to ensure they are clear, actionable, and aligned with our goals.
This step ensures that all perspectives are considered, leading to more robust and comprehensive user stories.
2. Addressing Comments
Once we’ve gathered feedback, the next step is to address these comments systematically. We review each suggestion and incorporate the necessary changes into our user stories. This iterative process helps refine the stories, making them more precise.
3. Identifying MVP/Version Story Candidates
With refined stories in hand, we then prioritise which ones will form part of our Minimum Viable Product (MVP) or a specific version of the product. This prioritisation helps us focus on delivering the most critical features first.
4. Moving Stories to MVP or Version Boards
To keep our workflow organised, we use boards to track the progress of stories. MVP stories are moved to the MVP board. This occurs again when moving stories into versioning boards. In each case we refer to our original board or Main board.
This visual organisation helps us:
- Track development progress.
- Ensure team alignment.
- Maintain a clear overview of upcoming work.
- Provide an archival reference.
5. Refining Acceptance Criteria and Creating Design Documentation
One key aspect of our workflow is maintaining consistency in user stories while allowing flexibility in acceptance criteria. We:
- Keep the core user story intact but refine the acceptance criteria to ensure clarity and testability .These acceptance criteria can be more relax or stringent as the product/capability evolves
- Create High-Level Design (HLD) and Low-Level Design (LLD) documents for the MVP or version. The more detail the better
6. Updating Jira Epics and Stories
The Epic for the selected feature/capability is updated to reflect its current state .This step is crucial for maintaining transparency making sure all stakeholders are on the same page. Updated tickets are tagged and allow us to track progress and manage dependencies effectively.
7. Iterating Through Versions
The final step in our workflow is to iterate through different versions of the product (V1, V2, etc.). We use our Main story matrix as a reference, allowing us to:
- Regularly reassess and adjust our plans based on feedback and changing requirements
- Ensure continuous improvement and alignment with our product vision
{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "Ensures AWS services are configured to be secure by default",
"Parameters": {},
"Resources": {
"S3AccountPublicAccessBlock": {
"Type": "Community::S3::PublicAccessBlock",
"Properties": {
"BlockPublicAcls": true,
"BlockPublicPolicy": true,
"IgnorePublicAcls": true,
"RestrictPublicBuckets": true
}
},
"EbsEncryptionDefaults": {
"Type": "Community::Organizations::EbsEncryptionDefaults",
"Properties": {
"EnableEbsEncryptionByDefault": true
}
}
},
"Outputs": {}
}