Programmers and Testers Can Work on Things Smaller Than User Stories

A common misperception is that testers cannot do any work during an iteration until the programmers finish a user story or product backlog item. However, the unit of transfer between programmer and tester can be smaller than the user story.

Let’s see how this could work through an example: Suppose a tester and I are working on the story about auto-incrementing the next check number in a checkbook management system. We would talk before getting started and agree that I’m going to go code the simple scenario where the user enters one check after another and that we’ll force the session to start with check 100. So entering five checks will give 101, 102,...105. The tester goes and writes an automated test for that while I code it. We check that in tomorrow morning and it becomes part of the nightly build. We’ve just exchanged work at a level smaller than the individual user story / product backlog item. Let’s do it again.

Next the tester and I talk and agree that we want to read the last check number from the file storage part of our product. So now our check numbers have to start at the right place rather than always starting with 100. The tester writes the automated tests while I code. We both check in our work and add it to the nightly build. Next we decide to tackle the situation where the user doesn’t enter one check after another. Instead of check, check, check, check we want to handle sequences like check, check, deposit, EFT, check, deposit, check and make sure the check numbers are incrementing correctly. Then we decide to handle the case where the user manually types in a check number, overriding the default.

Perhaps an analyst figures out what to do in some edge cases around this part of the user story (do we warn the user they’re missing a check? does the sequence start to go off the last entered check number or the highest check number?). While the analyst figures that out the tester is automating and I’m coding. And so it goes....