Agile Testing: A Practical Guide for Testers and Agile Teams

Our team used to feel we didn’t have time to plan in advance for the next iteration. After many experiences of misunderstanding stories and having them far exceed estimations, and finding most “bugs” were missed requirements, we decided to budget time in the iteration to start talking about the next one. Now the whole team, including the product owner and other customers as needed, meet for an hour or less the day before the planning meeting for our next sprint.

We laughingly call this the “pre-planning” meeting. We go over the stories for the next iteration. The product owner explains the purpose of each story. He goes over the business conditions of satisfaction and other items in his story checklists, and gives examples of desired behavior. We brainstorm about potential risks and dependencies, and identify steel threads where appropriate.

Sometimes it’s enough to spend a few minutes listening to the product owner’s explanation of the stories. At other times, we take time to diagram thin slices of a story on the whiteboard. Figure 16-1 shows an example diagram where we got into both the details of the UI flow and the database tables. Note the numbers for the “threads.” Thread #1 is our critical path. Thread #2 is the second layer, and so on. We upload photos of these diagrams to the wiki so our remote developer can see them too.

Figure 16-1 Sample planning whiteboard diagram

We can start thinking about what task cards we might write the next day and what approach we might take to each story. For some reason, being able to ruminate about the stories overnight makes us more productive in the actual iteration planning meeting the next day. After doing this for a few iterations, we were spending less time overall in planning the iteration, even though we had two meetings to do it.

Sometimes we pull in other customers to discuss stories that affect them directly. If they aren’t available right then, we still have time before our iteration planning meeting to talk to them to clarify the story.

In one pre-planning meeting, our product owner introduced a story about obtaining performance data for mutual funds. We would send a file to the vendor containing a list of mutual funds, and the vendor would provide an XML file on a website with all the latest performance information for those funds. We would then upload that data into our database.

In the pre-planning meeting, we asked questions such as, “What’s the format of the file we send the vendor?” “Is the ‘as-of’ date for each fund always the last day of the month?” “Is there any security on the website that contains the XML?” “Will we ever get a record for the same fund and “as-of” date that has new data, or can we ignore records with a date we already have in our database?”

By the next day’s iteration planning meeting, the product owner had obtained answers to all our questions. Writing task cards went quickly, and coding could proceed with correct assumptions.

Often, we find a much simpler solution to a story when we discuss it in the pre-iteration planning discussion. We found that to go fast, we needed to slow down first.

—Lisa

Do You Really Need This?

Your team may not need much or any advance preparation. Pierre Veragen and Erika Boyer described to Lisa how their teams at iLevel by Weyerhaeuser write user acceptance tests together at their iteration kickoff meeting.

These tests, which were written on a wiki page or some similar tool along with the story narrative, are used later when team members write task cards for each story and start writing more tests and code. Examples are turned into executable tests. Because the tests change as the team learns more about the story, the team may opt not to maintain the original ones that were written at the start. Keep it simple to start with, and dig into details later.

Lisa subsequently observed one of their planning sessions and saw first-hand how effective this technique was. Even when the product manager provides concrete examples, turning them into tests may flush out missing requirements. Their team did not need to do this before the iteration planning session, but it is not the case with all teams.

Lisa’s Story

My team liked the practice of writing tests together, but because we were writing task cards during iteration planning, we decided to write user acceptance tests together during the pre-planning meeting. We found this kept our discussions focused and we understood each story more quickly. We also did a better job of delivering exactly what the customer had in mind. Our customers noticed a difference in quality, and our product owner encouraged us to continue this practice.

—Lisa

Experiment with short pre-iteration discussions and test-writing sessions. It’ll take you several iterations to find your team’s rhythm, and find out if advance story discussions make you more productive during the iteration.