Agile Testing: A Practical Guide for Testers and Agile Teams полностью

Some teams don’t spend much time doing release planning activities. Priorities change quickly, even within a particular theme of features. Nobody wants to do too much work up front that ends up being wasted. Some teams just look at the first couple of stories to make sure they can get a running start. At the very least, teams want to know enough to get their system architecture pointed in the right direction and get started on the first few stories.

These planning meetings aren’t intended to plan every iteration of the release in detail. And we know we can’t predict exactly how many stories we can complete each iteration. However, we do have an idea of our average velocity, so we can get a general idea of the possible scope of the release. The team talks about the features and stories, trying to get a 20,000-foot view of what can go into the release and how many iterations it might take to complete. Both of us like Mike Cohn’s approach to release planning in his book Agile Estimating and Planning [2005]. Stories that the business wants to include are sized relative to each other, and then features are prioritized according to the value they deliver. The team may identify “thin slices” through the features to determine what stories absolutely have to be done, what’s in scope, what “nice-to-haves” could be put off until later. They look at dependencies between stories, relative risk, and other factors that determine the order in which features should be coded. The order in which stories are coded is as important, or sometimes more important, than the size of the stories. Teams want to deliver value the first iteration of the release.

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.