Agile Testing: A Practical Guide for Testers and Agile Teams

While the product owner balanced all the different needs and presented the final statement layout, it was still important for our team to understand the purpose behind each new piece of information. We needed to talk directly to business experts in the plan administration, business development, and legal areas, and to the product owner. A tester and a programmer met with each group to gather the different viewpoints. By doing this before starting on stories to gather and display data, we understood the requirements much more clearly and even made suggestions to produce the information more efficiently.

—Lisa

Make sure you are as efficient as possible in collecting this data. Sometimes it is important for the whole team to understand the need, and sometimes it is sufficient for one or two of the team members to do the research.

Story Size

As you discuss stories for the next iteration with the customer team members, ask questions to help them make sure each story delivers the value needed. This is a good time to identify new stories they might need to write. Even though the team sized the stories previously, you might find a story is bigger than previously thought. You might even discover that a feature can be implemented more simply than planned, and the story can be smaller.

Sometimes assumptions are made when the story is sized and on further investigation turn out to be false. Even simple stories deserve a closer look. It’s hard for any one person to remember all the details of an application.

Lisa’s Story

Here are some examples of stories that turned out to be significantly bigger or smaller than originally thought.

1. The story was to produce a file of account statements for all participants in a given company retirement plan, which was to be sent to a vendor who would print and mail the statements. It was originally sized with the assumption that all statements were exactly three pages long. Upon further investigation, we discovered that some participants had four-page statements, but the vendor required that all statements be the same length. Our business experts had to decide whether to have a feature to flag any plans whose participants had four-page statements and deal with those manually, or change the statements to make them all four pages long. That’s a much bigger effort than the original story. After we started developing the story, the customers revealed another requirement: If any participant’s address was missing or invalid, the statement should be mailed to the employer instead. It’s reasonable, but we didn’t know about it when we sized the story.

2. Our customers wanted to start displaying the sales phone number in various locations in the UI. There is a different sales phone number for each partner’s site, and at the time there were about 25 different partner sites. This sounded like such a straightforward story that it wasn’t even given to the team to size. The development manager just assigned it a small point value, and it was just “added” to the iteration. He had assumed the phone number was stored in the database, when in fact it was hard-coded in the HTML of each partner’s “contact” page. Storing the correct number for each partner in the database, and changing the code to retrieve the value, made the story twice as big, and there wasn’t room for it in that iteration, so it did not get done.

3. We sized a story for the user interface to allow administrators to submit a request for a batch job to rebalance participant accounts that met a certain condition. It included a confirmation page displaying the number of participants affected. Because the request was queued to run as an asynchronous batch job, the code to determine which participants were affected was in the batch job’s code. Refactoring the code to obtain the number of participants at request time was a big job. After we started working on the story, we asked the primary user of the feature whether he really needed that number upon submitting the request, and he decided it wasn’t necessary. The story became much smaller than originally thought. We always ask questions to find out the true business value that the customers want and eliminate components that don’t have a good ROI.

—Lisa

These stories show that a few questions up front might save time during the iteration that could be spent figuring out what to do with new discoveries. However, we recognize that not all discoveries can be found early. For example, on the first story, a simple question about statement size may have prevented last-minute confusion about how to handle four-page statements, but the inaccurate address issue may not have been considered until it was being coded or tested.

We know there will always be discoveries along the way, but if we can catch the big “gotchas” first, that will help the team work as effectively as possible.

Geographically Dispersed Teams