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:

The BA and QA working against (instead of with) each other

The business analyst (BA) is the person responsible for understanding the objective of the product. They consider stakeholders’ needs and translate them into requirements in user stories.

The quality assurance analyst (QA) is the one who will monitor the development process to ensure that it fulfills the needs of the customer (ex: stakeholder and product owner) as described by the BA.

Clearly, these two roles are complementary. The QA needs the BA to understand the rules and needs of the business. Meanwhile, the BA needs the QA to ensure teams meet the identified requirements.

Throughout the development process, business and quality assurance analysts have several chances to collaborate. Teams should take advantage of these opportunities to avoid miscommunication and the dreaded disconnect between themselves and the client.

So how can we ensure effective communication between business and quality assurance analysts? The answer lies in user stories and acceptance criteria.

The Importance of User Stories and Acceptance Criteria

The development of a new feature begins before programming, when the sprint is still being planned. During this proactive period, it’s important to create a survey that clearly outlines the feature’s objective. The QA and the BA should agree on the user story and acceptance criteria. That way, both sides have a clear idea of what success will look like during the sprint.

Let’s look at a simplified example to better understand these terms:

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.

The QA and BA realizing how great it is to work together.

Final Tips

At each stage of development, follow these steps:

  • Analyze the user story and acceptance criteria/tests to find ambiguity or any deficiencies in them.
  • Ensure the conditions are clear, easy to understand, and objective.
  • Clarify questions and assumptions as quickly as possible.

By following the steps above, you can keep expectations between all parties in check. You can also avoid errors that cost everyone involved time and money. Want to learn more about having the most effective Agile teams possible? We recently wrote about Programmers’ unique Agile Experience approach.