As a team member of an Agile team, QA and any other stakeholders should be invited to all story mapping meetings....
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Ideally, making a polite request will be enough for developers to begin including you in Agile story mapping. If not, a degree of persistence may be necessary.
To accomplish your goal in a professional manner, I suggest you bring it up in the daily standups. If you don't have daily standups, set a time and discuss with the developers in person, if possible, or in an online meeting. Explain that as a QA you need all the background and design information possible in order to test effectively and contribute to the team. Whether you call a formal meeting or walk over and discuss, make sure you have valid business reasons written down in case you need to respond to pushback or adverse opinions.
If asking in a professional, respectful manner does not work, I suggest you trail the development team the next time a new project comes up. By trailing, I literally mean following them into meetings if you see them all get up and go, or checking their shared calendar for Agile story mapping sessions.
For the first meeting, take it all in and mainly listen. Listen carefully so you can sketch out an outline of the design and then create sample test cases for it. In this way, you're essentially creating your own prototype of the project. It doesn't need to be a formal test plan. Once you have outlined your ideas and have them organized with test cases, discuss it with one or more developers to get their opinions.
While you're developing test cases and a test strategy, come up with a list of ideas on what use cases are missing or not accounted for. Share your list during the next standup or team meeting. Ask again to attend any and all design discussions. In the early story mapping sessions, you'll want to listen and take notes more than anything else. As the team gets more comfortable, you can bring up ideas based on your prototype.
Don't underestimate the importance of preparation. As long as you're prepared, they'll know you're organized and have a plan. It's easier to gain respect when you're prepared. Even if you're off track of the ultimate design, the planning shows that you're willing to take time to better understand the design and project. It'll go a long way toward gaining the respect of your team and make you a more effective team member.
Additionally, you may consider getting the other stakeholders together and bringing up the issue at the next team retrospective meeting. Prepare a list of contributions the group intends to make and the need to develop the highest quality product as a team. Bring up your desire to contribute to the quality of the product. Agile story mapping and design discussions depend on full-team participation to be effective.
Learn about creating more customer-focused apps with story mapping
Learn more about Agile story mapping and requirements gathering
See what Amy Reichert has to say about continuous requirements gathering
Dig Deeper on Software Requirements Management
Related Q&A from Amy Reichert
The software testing profession is changing rapidly, thanks to DevOps and automation. But some of the skills you'll need to keep up are surprisingly ...continue reading
Trying to identify bottlenecks in the software testing process can be challenging, but starting a lean QA effort can help. Expert Amy Reichert ...continue reading
You can't test something if you don't know what it's supposed to do. Often, testers have a very incomplete understanding of what they're testing. ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.