Crispin, Lisa - Agile Testing - A Practical Guide for Testers and Agile Teams

If your situation is so dynamic that stories might be re-prioritized the day that the iteration starts, it isn’t worth trying to do this planning. Instead, make sure you budget time for these discussions during your planning meeting.

Advance Clarity

Lisa’s product owner, Steve Perkins, came up with the term “advance clarity.” Different parts of each organization have different priorities and agendas. For example, Business Development is looking for new features to attract new business, while Operations is prioritizing features that would reduce the number of phone calls from users. The development team tries to understand the range of business needs and get a feel for each individual’s job.

With many different agendas, someone needs to decide what stories should be implemented in the next iteration. Because there are many ways to implement any given story, someone has to decide the specific requirements and capture them in the form of examples, conditions of satisfaction, and test cases. Steve gets everyone together to agree on the value they want from each story, and to provide “advance clarity.”

Customers Speak with One Voice

Scrum provides the helpful role of the product owner to help all the customers “Speak with One Voice.” Whether or not you’re on a Scrum team, find some way to help your customers agree on the priority of the stories and how the components of each story ought to be implemented. Management support is crucial, because any person in this role needs time and authority to get everyone on the same page.

Other teams use business analysts to help flesh out the stories before the next iteration. In one organization Janet worked with, the customers were not available full-time to answer questions, but each team had a business analyst that worked with the customers to flesh out the requirements before the iteration planning meeting. If there were any questions that she could not answer at the meeting, the team either called the customer directly or the analyst followed up immediately after the meeting.

As a tester, you want to sit in on story writing and prioritization meetings. Ask questions that help the customers focus on the core functionality, the critical business value they need. Help participants stay focused on concrete examples that crystallize the meaning of the stories. In meetings that involve multiple customers, it is critical to have a strong facilitator and a method for determining consensus.

As with code, stories are best if they have the bare minimum. For example, an Internet shopping cart needs some way to delete unwanted items, but the ability to move items from the cart to a “save for later” list can probably wait. It may be helpful to talk about this before the iteration, so that the team is clear on what tasks need to be planned. Focus on the simplest thing first and use an example to make it clear.

Get All Viewpoints

Getting requirements from different customers for a story, each of whom has a different agenda, might create chaos. That’s why it’s essential for someone on the customer team to get consensus and coordinate all points of view. This doesn’t mean we shouldn’t get input from different customers. As a tester, you’re considering each story from multiple points of view. It helps to know what the story means to people in different roles.

Lisa’s Story

When my company decided to redesign the retirement plan participants’ quarterly account statements, different people on the business side wanted changes for different reasons. The plan administrators wanted a clearly understandable layout that would minimize the number of calls from confused participants to customer support.

For example, they wanted the statement to show the date and amount of the participant’s most recent contribution. This helps the participant know whether her employer is late in posting contributions to the accounts. Business development wanted jazzy new features that they could sell to potential customers, such as graphs of performance by fund category. Our legal person needed some new text and data on the statement to satisfy federal regulations.

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.