kentoh - Fotolia

QA should be present for Agile story mapping

What is a respectful way to insist that QA and other stakeholders be included in Agile story mapping for new projects?

As a team member of an Agile team, QA and any other stakeholders should be invited to all story mapping meetings. 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.

It's easier to gain respect when you're prepared.

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.

Next Steps

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 Topics Archive