Agile Testing: A Practical Guide for Testers and Agile Teams

Figure 15-1 Planning poker. Used with permission of Mike Thomas. Copyright 2008.

Some teams figure the relative sizes of stories by how many people are needed to complete a given story in a set amount of time. Others estimate how many ideal days one person would need to finish it. Use a measurement that makes sense to all team members and one that provides consistency among estimates.

The Tester’s Role in Sizing Stories

One of our favorite sayings is, “No story is done until it’s tested.” However, we’ve run across teams where testing wasn’t included in estimates of story size. In some cases, testing a piece of functionality might take longer than coding it.

In our experience, testers usually have a different viewpoint than other team members. They often have a broad understanding of the domain and can quickly identify “ripple effects” that one story might have on the rest of the system. They also tend to think of activities not directly related to development that might need to be done, such as training users on a new or changed interface.

Lisa’s Story

What does a tester do during the story sizing process? I think quickly about the story from several viewpoints. What business problem is the story solving, or what business value does it deliver? If this isn’t clear, I ask the product owner questions. How will the end user actually use the feature? If it’s still not clear, I ask the product owner for a quick example. I might ask, “What’s the worst thing that could go wrong with it?” This negative approach helps gauge the story’s risk. What testing considerations might affect the story’s size? If test data will be hard to obtain or the story involves a third party, testing might take longer than coding. I try to quickly flush out any hidden assumptions. Are there dependencies or special security risks? Will this part of the application need to handle a big load?

Many stories aren’t big enough to warrant that much thought. Usually, we don’t need much detail to get an idea of relative size. However, your team can really get burned if a story is underestimated by a factor of five or ten. We once gave a relatively small estimate to a story that ended up being at least ten times the size. These are the disasters we want to avoid by asking good questions.

—Lisa

Testers need to be part of the sizing process. Some teams think that only programmers should participate, but when testers are active participants, they can help to get a much more accurate story sizing, which is in the best interests of the whole team.

An Example of Sizing Stories

Let’s imagine we have the story in Figure 15-2 to size up.

Figure 15-2 Story to delete items

After the product owner reads the story, the following discussion ensues:

Product Owner: “We just want some easy way for users to delete items, but we don’t have a specific implementation in mind.”

Tester: “Should they be able to delete several items at once?”

Product Owner: “Oh, yes, just make it as easy as possible.”

Tester: “What if they accidentally delete an item they wanted to buy?”

Product Owner: “Is there some way the deleted items can be saved for later retrieval?”

Programmer: “Sure, but you should write a new story for that. For now, we should start with the basic delete functionality.”

Tester: “Last release we implemented a wish list feature. Do you want users to be able to move items from their shopping basket to their wish list? That would be a new story also.”

Product Owner: “Yes, those are two more stories we want to do, for sure. I’ll write those down, we can size them also. But we could definitely put them off until the next release, if we have to.”

Tester: “What’s the worst thing that could happen with this feature?”

Product Owner: “If they can’t figure out how to delete, they might just abandon their whole shopping basket. It has to be really easy and obvious.”

The ScrumMaster calls for an estimate. The team understands they’re sizing only the basic story for deleting items, not for doing something else with the deleted items. They quickly agree on a point value.

Let’s look at another story. (See Figure 15-3.)

Figure 15-3 Story on shipping speed

Tester: “What are the shipping speeds the user can choose?”

Product Owner: “Standard 5-day, 2-day, and next-day.”

Programmer: “We should probably start by only offering one speed, and calculating that cost. Then we can easily implement the other two speeds.”

Product Owner: “It’s fine to break it up like that.”

Tester: “Will we use BigExpressShipping’s API to calculate cost based on weight and destination?”

Programmer: “That would be the easiest.”