Arriving at User Stories in a roundabout way

I was once a QA Lead on a project that was transitioning from Waterfall to Agile. Instead of a big handoff between QA and Dev every 2 weeks, we were trying to get to the point where QA was testing right alongside Dev (testing things as soon as they were ready on a daily basis).

The biggest challenge with moving to Agile was not a technical one. There was really no technical differences between the two (accept maybe a bigger emphasis on Unit and Automated tests). No, the biggest challenge with moving to Agile was COMMUNICATION.

The problem was that the handoffs had become so quick, and the cycles so short, that it was hard to accurately describe what was done (ready to be tested) and what was not done.

Dev would tell QA, “This part is done and ready, except for this part over here and that part over there.” And QA would find bugs, but we’d also find ourselves questioning whether the code we just tested was actually ready to be tested.

We realized this and tried to remedy it. QA and Dev began to meet every morning. We moved our seats around so that everyone was sitting in the same area. But still, something was missing.

It all came down to the GRANULARITY OF REQUIREMENTS.

With Waterfall, our Requirements Documents served their purpose well. Dev and QA could practically speak in terms of which pages of the Requirements Doc would be completed in a given iteration.

But with Agile, the Requirements Document was not granular enough. The identifiable chunks of functionality were too large to be able to use as conversational pieces. We needed something that would separate out a smaller unit of functionality, something that would be fast to write up and easy to pass back and forth between teams.

This is how we arrived at User Stories. User Stories turned out to be the perfect utility for the task at hand. They were just the right size to encapsulate a small unit of functionality, and allow us to accurately describe what phase of the process that unit of functionality was in.

We found User Stories in a roundabout way. Typically a development team chooses to go with User Stories because they find it is a better way to record requirements. We landed on them out of a need for a communication device.

More on User Stories to com.