Agile Testing: A Practical Guide for Testers and Agile Teams

The team holds up their point cards. The tester and one of the programmers hold up an 8; the other developers hold up a 5.

ScrumMaster: “Why did you two choose 8?”

Tester: “We’ve never used BigExpressShipping’s cost API before, and I’m not sure how that will impact our testing. We have to find out how to access their system for testing.”

Other Programmer with 8: “I agree, I think the testing effort is more intense than the coding effort for this story.”

The team agrees to size the story as eight points.

This sizing process may occur before the planning meeting, and if the stories were sized or estimated a long time ago, the team might want to make sure they feel comfortable with the story sizes. Teams may have changed or may be more experienced. Either of those factors can make a team change the estimates.

There are many times when a story will have a large testing component, and the coding effort is small. At other times, the reverse will be true. It’s important to consider all perspectives.

Lisa’s Story

Our team grew to dread story sizing meetings, because we got into overly long discussions about details, and the meetings always lasted long past the scheduled time. Since then, our ScrumMaster has found ways to keep us on track. She uses an egg timer to time discussions, and stops them each time the sand runs out to see if we think we really need more time to ask questions. Our product owner has also learned what information we need for estimating and usually has what we need. We also learned to only work on stories that were likely to come up in the next few iterations.

With all of our meetings, little traditions have grown to make the meetings more fun. Someone always brings treats to iteration planning meetings. In stand-up meetings, we pass around a combination penlight and laser pointer, so each of us holds it as we report on what we’re working on. We always end story sizing meetings with a competition to see who can throw his or her deck of planning poker cards into the small plastic tub where they live. Figure 15-4 shows this goofy but fun meeting-ending activity. Always remember the agile value of enjoyment and have some fun with your meetings.

—Lisa

Figure 15-4 A meeting-ending tradition. Used with permission of Mike Thomas. Copyright 2008.

Prioritizing

The purpose of the release planning meeting is also to get an idea of what stories the team will try to finish by the release date. The customers prioritize the stories, but there may be dependencies, so it makes sense to do certain stories first, even if they aren’t the highest priority. It is important that the team understands the possibility that not all of the stories will get completed by the release date. One of the basic premises of agile is to deliver working software, so it is important to have the highest-value stories completed first so that the software we do deliver meets the customer’s needs.

Why We Prioritize Stories

Everyone’s goal is to deliver real value in each iteration. Testers can help the team pick out the core functionality that has to work. In Chapter 8, we explained the “thin slice” or “steel thread” concept, identifying one path through the functionality to code and test first, and adding more features after the first critical path works. This concept applies at the release level, too. The order of the stories is critical. Lisa’s team will sometimes break up a story and pull out a core part of a feature to do in the first iteration.

Some teams that don’t do full-blown release planning do take time to look at the stories and decide which two or three should be first. That way, they deliver business value in the very first iteration of the release.

Let’s look at an example.