Picture this: Your scrum team just finished a development cycle and is ready to present its work to the customer. You all are eager to hear the feedback and think the presentation is going very well. But in the end, the client’s feedback is surprisingly negative. “That’s not what I asked for,” the client says. Your team goes from celebrating to franticly figuring out the next steps.

This situation is one of the biggest fears that scrum teams face. All the effort put into a development cycle feels wasted. Luckily, though, you can take steps through quality assurance to close the gap between expectations and reality. In this article, we’ll look at some of these fixes to the development process.

Business and Quality Assurance Analysts’ Roles

Frustration at the end of a cycle often comes when the development team’s quality assurance expectations do not align with those of the business team. Poor communication usually causes this disconnect. To better understand why this happens, let’s look at the professionals involved in these areas:

To summarize: The better a BA understands the needs of the business, the better they can write a user story. The more well-written a story, the easier it is to identify the acceptance criteria to satisfy the story’s purpose. Finally, the more accurate the acceptance criteria, the more definitive the acceptance tests.

So, what happens if a user story is poorly written and leaves too much room for interpretation? This will create errors and disfunction between the BA and QA. In the next section, we’ll learn more about these potential setbacks.

The Impact of Errors on Quality Assurance

The later you find an error, the greater its impact. Errors that go unnoticed until the acceptance test affect everything done before. Here are just some of the consequences of these errors:

• Underwhelming Product Launch – A product that launches below expectations can damage brand reputation. This also causes key stakeholders to lose trust in teams, casting doubt on product development going forward.
• Rework – The team will have to revisit previous phases to identify and fix mistakes.
• Losing Time – All the time spent developing and running invalid tests will now be used again to fix them.
• Cost Increases – The total cost of the project increases as your team needs to spend more time and resources with no added value to the company.

How to Avoid These Situations

According to the ISTQB (International Software Testing Qualifications Board), it’s important to resolve ambiguities about the product, its purpose, and development. Also, you should clarify assumptions to ensure the resulting acceptance tests are valid.

One of the techniques used by Agile teams to create user stories collaboratively and aim for higher quality is Mike Cohn’s “INVEST” strategy. This acronym serves as a guide to help you write high-quality user stories.

• [I]ndependent: User stories should be independent of other stories. That makes their delivery and development easier. Plus, it can avoid dependency bottlenecks such as, “I can’t do this task, because I need another one to be completed first.”
• [N]egotiable: User stories are not written in stone. They are negotiable between parties and can change before an iteration. That way, you can maximize the value of each delivery.
• [V]aluable: Speaking of value, user stories should always add value to the end-user.
• [E]stimatable: It should be possible to estimate the size of a story. This gives you a good idea of the development time you’ll spend on it. It also helps you understand what will or can be affected by implementation, which allows you to organize and prioritize stories.
• [S]mall: Small stories can be more objective and easier to estimate and deliver. That’s why they’re a great fit for Agile sprints.
• [T]estable: Stories need to be testable. Through testing, we can measure if the story meets all the end-users’ needs.

The INVEST technique is a good practice that helps to create clear and reliable stories. That minimizes potential problems and helps define expectations between business analysts, quality assurance analysts, and other important parties. If you want to learn more about writing user stories, read our recent blog post.