The Inovis Blog

I recently did a vlog about the old way and new way that QA has conducted testing. Before we started operating with user stories, we would use several requirements documents like the Market Requirements Documents and the Functional Content Specification as the basis for our requirements. Until we had plenty of reviews from the teams who were responsible for delivering these, we may or may not have had a full understanding of what the requirements were. The problem that we encountered with this process was that getting through all of these reviews could take two months or more. By that time, the relevance of what we were delivering may have no longer been current. It was almost impossible for us to predict six to nine months ahead of time what the customers were going to need, and many times the needs were different from when we started a project to when we finished it. Another issue we encountered was that we weren’t able to deliver on time in most cases, furthering the staleness of the delivered products. We’d plan for six to nine months and deliver in twelve months.

Along with the implementation of Scrum [at Inovis] came the concept of “User Stories.” User stories are beautiful because they allow a product owner togive us requirements in the form of a simple sentence. For example, in the book I’m currently reading, User Stories Applied, Mike Cohn describes user stories as a written description of a story used for planning, a conversation about the story that happens between a product owner and the delivery team, and tests that validate how we’ve got the user story implemented. It’s very simple. User stories come from the product owner, who serves as the voice of the customer. Through constant communication with the customer, the Product owners know what the customer is looking for and will be working with QA, Development, and the rest of delivery team to ensure we are distributing exactly what the customer wants.

User stories are a great source for test cases as well. User stories may be as simple as s sentence, but, through conversations with the Product Owner, the delivery team can derive a complete set of acceptance and functional test cases from that user story.. The conversations between the delivery team and the product owner that will help better define “done” – the point at which we know when we actually have that user story fulfilled. So, for example, let’s say that we want a resume posting service. The user story is, “a user can post his or her resume to the website.” Keeping this user story in mind, we go through a bunch of different questions and answers with the product owner to define what this means. Is there a certain browser you have to have? Does the resume have to be a certain format? Can it be a Word document? Can it be a PDF? Is there a certain length requirement? Does it have to be in a certain language? Does it only work in English? By engaging in this conversation with the Product Owner, we have defined the criteria that will meet that specific user story. Next, QA and development will write the test cases, go develop the code, and by the time we’re done delivering that user story, we’ll know that we’ve met the requirements because QA has received everything it needs to test it, development has obtained everything necessary to develop it, and we don’t deliver more than we’re tasked with.

As mentioned in a previous blog (or vlog), the SCRUM allows for a much shorter development cycle. With the old Waterfall methodology that we used, the cycles were so long that often times the end product was completely irrelevant or it was so out of date by the time it was released that the customer wouldn’t even want it anymore. Our new methodology and utilization of user stories allows us to have much better defined smaller requirements that may be completed in small intervals. For instance, we may have a sprint—our two week intervals—which may contain six user stories and may be broken up into twenty tasks and a hundred test cases, but we’re going to complete this work in two weeks. Our requirements are much better defined and a lot less ambiguous with this new process. By completing only the work needed to fulfill the user stories selected for a sprint we are able to focus on delivering only what is required to satisfy those user stories, allowing for more focused development work and more targeted testing. Also, we are delivering in a more timely manner functionality that is relevant to the customers at that time. It’s a huge improvement over the former methods we adhered to. User stories help make this possible.

And THAT is user stories in a nutshell.