Agile Testing: A Practical Guide for Testers and Agile Teams

One common exercise used in iteration retrospectives is “start, stop, continue.” The team asks itself: “What went well during this past iteration? What happened that shouldn’t happen again? What can we start doing to help with things that didn’t go well?” Each team member can suggest things to start doing to improve, things to stop doing that weren’t working, and things that are helping that should be continued. A facilitator or ScrumMaster lists them on a whiteboard or big piece of paper. Post them in a location where everyone can read them again during the iteration. Figure 19-1 shows a “stop, start, and continue” retrospective in progress. The ScrumMaster (standing) is writing stop, start, and continue suggestions on the big piece of paper on the story board.

Figure 19-1 A retrospective in progress. Used with permission of Mike Thomas. Copyright 2008.

Agile Retrospectives: Making Good Teams Great [2006] has imaginative ideas for making retrospectives more productive (see the bibliography).

Some teams start this process ahead of time. All team members write “start,” “stop,” and “continue” items on sticky notes, and then during the retrospective meeting they put the stickies on the board and group them by topic. “Start, stop, continue” is just one example of the terms you might use. Some other ideas are: “Things that went well,” “Things to improve,” “Enjoyable,” “Frustrating,” and “To Try.” Use whatever names that work for you. It can be hard to remember the past two weeks, much less an entire release, if that’s what your retrospective covers. Research different creative approaches to reflecting on your team’s experiences.

Here’s a sample “stop, start, continue” list from Lisa’s team:

Start:

Sending out next sprint’s stories to us earlier.

Don’t do lazy, single-record processing. Think of every service call as a remote call.

Communicate any database changes to everyone.

Stop:

Accepting stories without complete requirements.

Continue:

Running FitNesse tests for the code you’re working on.

Documenting what came up in meeting or informal discussions.

Communicating better with each other.

Showing mock-ups early.

Doing FitNesse driven development.

If the list of “start, stop, continue” items is long, it’s a good idea to choose one or two to focus on for the new iteration. To prioritize the items, give each team member “n” votes they can assign to items. The ten people on Lisa’s team each get three votes, and they can apply them all to one item if they feel that’s most important, or they can vote for two or three different items. The items with the most votes are noted as the focus items. Janet has had success with this way of prioritizing as well.

In addition to “start, stop, continue” items, the team may simply write task cards for actions to be undertaken the next iteration. For example, if the ongoing build is too slow, write a card to “get ongoing build under ten minutes.”

In the next iteration, take some time to look at the one or two focus items you wanted to improve. At the end of that iteration, take a checkpoint to see if you improved. If not, ask why. Should you try something different? Is it still important? It could be it has dropped in importance or really wasn’t important in the big picture. If you thought you improved on a problem area and it resurfaces, you’ll have to decide to do something about it or else quit talking about it.

We’ve found that retrospectives are a simple and highly effective way for teams to identify and address issues. The retrospective meeting is a perfect opportunity to raise testing-related issues. Bring up the issues in an objective, non-blaming way. The team can discuss each problem, what might be causing it, and write down some ideas to fix it.

Ideas for Improvements

Let’s take a look at some of those items that made it onto the list for improvement. Too many times, a team will identify really big issues but never follow up and actually do something about them. For example, maybe a lot of unit-level bugs are discovered after the programmers have claimed coding was complete.

The team may decide the programmers aren’t covering enough code with unit tests. They might write an action item to run the code coverage tool before they check in new code, or start writing a “unit tests” task card for each story to make sure they’re completed. Perhaps the team didn’t finish all the test automation tasks before the iteration ended. As they discuss the problem, the team finds that the initial executable tests were too complex, and they need to focus on writing and automating a simple test first, or pair for a better test design. Make sure the action items are concrete.