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

Release planning is a chance for the developers and customers to consider the impact of the planned features on the larger system, clarify assumptions, and look at dependencies that might affect what stories are done first. They may think about testing at a high level and whether new resources such as test environments and software will be needed.

Let’s follow our agile tester through release planning activities and see how she contributes value through her unique perspective and focus.

Sizing

Agile teams estimate the relative size of each story. Some teams size as they go, delaying the estimation until the iteration where they’ll actually complete the story. Others have meetings to estimate stories even in advance of release planning. Some developer and customer teams sit together to write and estimate the size of stories all at one time. The goal of sizing is for the programmers to give the business an idea of the cost of each story and to help them prioritize and plan the first few iterations. High-functioning teams who’ve worked together for years may take a less formal approach. For new agile teams, learning to size stories takes a lot of practice and experience. It’s not important to get each story sized correctly but to be close enough to give customers some idea of how big the stories are so they can prioritize with better information. Over time, variations on individual story sizing will average out, and we find that a theme or related group of stories takes about the amount of time expected.

How to Size Stories

As far as how to calculate story size, different teams use different techniques, but again, we like Mike Cohn’s approach to determining story size. We size in story points, ideal days, or simply “small, medium, large.” The relative size of each story to others is the important factor. For example, adding an input field to an existing user interface is obviously much smaller than developing a brand new screen from scratch.

If the business knows the average velocity (the number of story points the team completes each iteration) and has the initial size estimates of each story it wants to get done, it has an idea of how long it might take to implement a given theme. As with any other development methodology, there are no guarantees, because estimates are just that. Still, the business can plan well enough to conduct its usual activities.

Our teams use planning poker (explained in Mike Cohn’s book Agile Estimating and Planning ) to estimate story size. In planning poker, each team member has a deck of cards. Each card has a number of points on it. The process begins with the customer or product owner reading a story and explaining its purpose and the value it will deliver. He might list a few conditions of satisfaction or high-level test cases. After a brief discussion, team members each hold up a point card that represents how “big” they think the story is from their perspective. They discuss any big differences in point value and estimate again until they reach consensus. Figure 15-1 shows team members talking about the point values they each just displayed. This needs to be a quick process—long discussions about details don’t result in more accurate size estimates.

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.”