We hope you’ll join us at Agile Testing Days in Potsdam this December, and we invite you to join our tutorial on Day One! Our tutorial title is “Exploring Features and Stories: How Testing Helps Build Shared Understanding”. Lots of words – what do we mean by that? What might you learn in our hands-on tutorial? Here’s a sneak preview!

Building shared understanding

Delivering the right thing – is it a myth? (picture: www.squirrelpicnic.com)

I’ve often had this experience, even on “high functioning” agile teams: The product owner brings us a feature, we work hard to develop that code using technical- and customer-facing tests, the code is robust and solid. We demo to the customer, and are surprised to hear, “That’s not what I wanted!” Sometimes we may release a new feature to production, only to realize we missed some key functionality.

We can avoid most of this frustration and wasted effort by making sure we all share the same vision of why the business needs the feature, who will be using it, and how it should work. It’s a team effort, and testers with an agile testing mindset can bring so much to the party as we elicit specifications and explore requirements. Here are just a few of the techniques you’ll get to practice during our tutorial day.

7 Product Dimensions

7 Product Dimensions

In their book Discover to Deliver, Ellen Gottesdiener and Mary Gorman share a wealth of agile business analysis practices that help make sure we address all types of quality that our customers may want. We’ve found the 7 Product Dimensions especially useful. I use them as a “cheat sheet” to prompt questions about a new feature. Some are more obvious – who will use the feature? Some we often forget about – what policies, regulations and rules may impact the feature or be affected by it? A key area is the quality attribute dimension – those little things like security, stability, and testability. Asking questions about these dimensions of quality helps the customer and technical teams quickly get on the same page.

Process map or flow diagram

Process Map / Flow Diagram

We’ll include tried and true techniques such as using process maps, also known as flow diagrams, to visualize the flow of work. Stakeholders and the software team members collaborate to map the sequence of actions included in the feature set, the materials or services being passed through as inputs and outputs, decision points, the various people involved, how much time is needed at each step. Talking things through while illustrating the flow helps flush out hidden assumptions and “unknown unknowns”.

Example mapping

Example Example Map from JoEllen Carter (testacious.com)

For many years, Janet and I have used the “Power of Three”, explained in our first book Agile Testing, involving a business expert, a developer and a tester in any discussions about feature or system behavior. (Some people call this “Three Amigos”, as described by George Dinwiddie). Recently we learned a technique that makes these conversations even more productive: Example Mapping from Matt Wynne. We get the Amigos together – perhaps also including a designer, database or operations expert – to capture business rules along with the examples that illustrate how the business rules work. This is a quick way teams can prepare their stories for iteration planning meetings.

Add lots to your toolbox, and help your team have more fun!

We hope you’ll join us on the 5th of December for a day of practicing ways teams can quickly build shared understanding of features, and make sure they deliver the right thing. Please register now!