In a good environment that understands acceptance criteria (that they are insufficient, coded guidelines and not an abstract interface to checking tools as a replacement for thinking) I find that a few things help:
- Understand the story. You are no good if you can’t decide on the value of your input.
- Keep and refer to risk catalogues. What are the usual risks on your project? What’s gone wrong recently? Do they apply here?
- Keep and refer to strategy models. I like the HTSM, or usually a cut-down version of it that’s more applicable to my project and team.
- Look at the story BEFORE you discuss it in a group, wherever possible. Test the story, come up with risks ahead of time and establish questions you have. Then you won’t waste anyone’s time, plus you’ll look thorough and super smart.
- Make testability a goal of a story. A story isn’t complete until it’s testable. If you need generated test data, or access to a third-party system, or an interface to hook in a test tool like an automation suite, or a log file for observability then you need to ask for it and make sure it gets done.
- Apply critical thinking to the story, models and conversation. I like Huh? Really? So? And? for this.
Another tip is to use explicit models. Have a diagram with you or get someone to draw one, then you can test that. What does this box mean? What does this arrow mean? What if I remove this? What’s missing from this diagram? This helps explore people’s assumptions about what everyone else thinks and understands, and what nobody has thought of yet.
If you keep good notes and models handy you can act as a body of knowledge on product risk, testability, historic problems and potential catastrophe. Then people will be all like get a load of this person being all good and stuff.