kentoh - Fotolia

Manage Learn to apply best practices and optimize your operations.

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

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

An excellent question :) Ha, I love the idea of "trailing" the development team (in my case, it is not the whole team, it is the dev manager and the service line manager who go off on their own and do story mapping types of activities).

It's funny because we had a former QA lead who would simply invite herself to meetings by just walking in if it looked like something important was going on without her. It always made me chuckle to myself. I never felt like I could do something like that, but I think that I might have to.
Testers sometimes do end up a little like spies with the need for reconnaissance in order to get data we need to do our jobs.  I don't think testers are intentionally ignored, rather it is assumed we can only do work once the software is done.  Changing that view in an organization can lead towards changing the entire culture with regards to quality.
I was with the idea until the test cases part.

There should definitely be test ideas available after sitting in a story mapping meeting.  However, even if I believed in prescriptive test cases in (and I don't) I'm not sure that in all cases you can get that detailed at the point that mapping is happening.
QA/testing folks often find themselves left out of various requirements activities that they think they should be participating in. I’ve found that their often-main motivation, “as a QA you need all the background and design information possible in order to test effectively,” tends not to persuade the other folks to invite QA in. Instead, QA needs to think primarily in terms of adding value for the others to the requirements activity. Then QA actually has to provide said types of value, which usually means they indeed must be prepared beyond merely “being from QA and here to help."
I think a lot of this question depends on what happens in the story mapping meeting in the first place. It's hard to know whether the information presented in a meeting is really going to be relevant until you know what happens there.

One technique that has worked for our testing group is to ask to have a 'representative' in the meeting. One person there to listen is usually pretty reasonable. That person can then pass along information about the meeting to the team, and then we can make a better decision on how useful the meeting is to us, whether we need to continue sending a representative.
Since QA is part of the development framework/cycle, they should use data that highlights how high performing IT organizations work -
Brian that is a fascinating report.

Continuous delivery requires that developers, testers, and UX, product and
operations people collaborate effectively throughout the delivery process."

I couldn't agree more. There are many other take-aways in the report, too. I might have to send it out to my team and see if others would be interested in reading it.