Hawkeye technique for building right product: Specification-By-Example
We all know the importance of validating a feature before committing to getting it built. Validating assumptions help in avoiding the most frustrating and common problem – building something that nobody wants. However, validation is easier said than done. Building the right feature before we think of building the feature right is the key.
Being Agile, we always try to leverage the quick feedback loop and adapt based on the end-user feedback. That’s good but it should not be used to validate the assumptions and that too after implementing a feature based on that assumption. It’s very expensive
A more powerful and productive technique is to leverage Specification-by-example in defining and discovering requirements collaboratively with end-user, even before start working on the feature.
This talk will focus on highlighting key aspects of effectively adopting SBE technique based on my own experience leveraging it successfully over and over again. It not only helps in grooming the feature requirement to tell a clear , simple and compelling story but it also helps in removing what is not needed.
Outline/Structure of the Experience Report
- Quick introduction about myself (1 min)
- Why we need Specification-By-Example (5 mins)
- Validating usability of feature by end users
- Defining and discovering requirements
- Defining functional specification
- Conversation with users/SME to collaboratively specify requirements
- Defining ubiquitous language used across all the parties that are involved
- Defining acceptance criteria for the successful development of the feature
- Eliminating communication gap
- What is it really? (5 mins)
- Defining requirements in domain specific language
- Walk-thru of different phases of defining SBE
- Automatic validation of requirement and that too continuously
- How to effectively create it? (5 mins)
- When to create it?
- Who all should participate in it?
- What is “3 Amigos” meeting or grooming session?
- What level of granularity to be captured?
- How many examples are good enough?
- Who should author the examples?
- How to ensure that everyone in the team is on the same page about the understanding?
- Who should verify it?
- How to ensure that the developed feature fulfills the acceptance criteria?
- How to ensure it’s always verified with new features getting build over it?
- Where does it fit in Agile? (2 mins)
- Crafted while grooming stories
- Definition-of-Ready (DOR)
- Automated funcational tests
- Q&A (2 mins)
- Understanding about Specification-by-Example
- How to effectively leverage it in building the right feature
Developers, Testers, Product Owners, Business Analyst, Scrum Masters
schedule Submitted 6 years ago
People who liked this proposal, also liked:
Ankur Sambhar - Promiscuous Pairing - More the merrier !!!Ankur SambharVice PresidentJ P Morgan
schedule 6 years agoSold Out!
Being Agile developer, have tried & tested various flavors of pair programming over the years while working in highly motivated self-managed team. Some experiments worked while some worked better :)
This talk is about sharing the personal experience of practicing promiscuous pairing which allowed the team to be always in the beginner's mind state and being able to push the boundaries consistently.
This experience sharing talk is based on our successful adoption of the promiscuous pairing technique based on very famous research paper by Arlo Belshee "Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience".