The need to improve the time-to-market of a quality product and adapt to a changing business environment are driving organizations to adopt agile practices in order to be competitive in the marketplace. However, a project team is bound to face difficulties if it is not trained on the fundamentals of agile. The purpose of this article is to discuss a situation I recently encountered in which the team I was working with was not formally trained in agile. The team was composed of a product owner (a representative from the customer), project coordinator (an intermediary between the project team and product owner), developers, and testers. The team was geographically distributed, with the project coordinator and product owner located close by and the project team comprising developers and testers located together in a different time zone.

Due to this kind of team formation, the product owner was not available up front to explain the user stories, their acceptance criteria, and how the system fit into the context of the customer’s existing systems. In general, the project coordinator did his best to convey the meaning of user stories but failed to express the user stories effectively to the project team. In this project, iterations (timeboxes) of different durations were planned for the implementation of features. Hence, we did not gain benefits that are generally realized in the case of sprints of fixed length and the same duration. Realizing the fact that the team was not well-versed in agile, a framework was designed to provide a structured approach to manage the various challenges.

Challenges with Our User Stories
A user story is a promise for a conversation. This means less information is available to the team for understanding the intricacies of requirements. As a result, the team relies on individual competency rather than a structured framework that ensures the features meet the users’ expectations.

In the absence of a product owner, a complex user story is often subjective to the interpretation of reader. Such a story often has a statement expressed in the common language of the business community; a technical product team might not be conversant with such terms. In this case, the team has to make assumptions about the terms based on the context of the statements. The team members may eventually realize that the intended meaning of the terms is different from their assumptions, but this realization will create more work as well as a negative perception about their understanding of the business objectives.

When user stories are poorly written, dependencies exist between the user stories that were released in different iterations (timeboxes). Consider the case of the following two iterations.

The first iteration, labeled iteration1, has functionality in which the status is changed depending on the user’s action. The second iteration, labeled iteration2, has a feature to display the status in some section of the screen. Assuming there is a considerable timeline gap between these iterations, it is possible to miss one of the status alerts to be verified on screen either due to an oversight or a failure to remember what iteration2 listed. The chance of such an occurrence cannot be ruled out because a user story usually specifies the user’s expectation for that screen and doesn’t provide correlation with other screens.

How We Used a Framework to Organize Our Testing and Manage Challenges
To address challenges in agile development or testing, we decided to create a framework to help us structure our testing.

Figure 1. Framework used to help structure testing

The following section outlines the details of various blocks present in the framework I presented above.

1. Understand Your Client’s Business and Its Problems
Business and technology have to go hand in hand in order to meet consumer demands. Therefore, it is imperative for the product team (developers and testers) to understand the client's line of business to gain any meaningful insight about the user story. Also, a team can find the missing link in the proposed solution architecture for the client’s problem, which allows it to identify the problem at a much earlier phase of development.

 2. Existing Products Help Teams Understand Their Client’s Business
A team can gain knowledge about its client’s existing products from the client’s website. Doing so allows team members to understand the high-level features without getting into finer details. Such information helps team members understand the limitations of the existing products, why the customer wants to build a better solution, and how this new solution impacts the products on a high level.

 3. Gist of the Proposed Solution
Knowing high-level architecture helps a team connect a problem with a solution. Along with the knowledge gathered in the previously listed steps, this will help a team visualize the landscape of its client's IT ecosystem and gives an idea of where the solution fits into the overall picture.

 4.  Information Exploration
Split the purpose of the story into three main parts: User/Objective/Reason. “As a [User], I want to [Objective] so that I can [reason].” Submit the statement so that we can identify the target user of the story, e.g., when an application has multiple user roles such as Buyer, Seller, and Agent, any statement like “As a [User]” signals ambiguity because the statement does not define the unique user for story. Instead the construction should be “As a [Buyer]....” Or “As a [Buyer] Or [Seller]....” .The objective defines what kind of action is expected to be performed by the user and also identify the reason behind the story. Read the information critically and analyze whether the objective makes sense for the user to accomplish the results. The following is kind of a mismatch that might be present in a user story: For a real estate website, the user story says “As a Buyer, I want listings (homes) to become viewable on the webpage so that it is clear that the home is no longer on the market.”

In the above example, an objective is that the listing is read-only and doesn’t allow the user to view further details about the home. But reason tells us that home is no longer on the market. By arranging different pieces of information, we notice a mismatch between the objective and the reason.

Asking critical questions, such as “Why does the user want the feature to be in place if he or she doesn’t want listings (homes) displayed on the website?” help us determine the purpose behind implementing the feature.

5. Splitting Acceptance Criteria
By closely examining the acceptance criteria, we can see that they resemble the objective of the user story. Any deviation from the objective will help us identify the discrepancy in the acceptance criteria.

You can compare the criteria with one another in order to learn how they are related. Consider the following designed scenario based on independent and dependent acceptance criteria. A shopping cart website has a screen that has acceptance criteria as follows:

1. Must show a notification for the user when a company has sent online offers
2. Sort the items based on the brand name, item names, etc.
3. Sort alphabetically

Point one is an acceptance criterion independent of points two and three. However, points two and three are dependent on each other for designing the scenarios.

6. Envision a User Interface
User experience, or UX, decisions generally happen after a user story is written. You should provide continuous feedback for the UX team, especially as the team identifies features that are not supported by the current UX design or the UX feature doesn't meet certain acceptance criteria. If prototypes are not available, testers needs to visualize the various types of objects—such as textboxes, buttons, and labels—and provide constructive feedback for the UX team.

7. External Systems
Sometimes an external system will impact the proposed solution. In this case, it is essential to understand the features present in these systems, either by hands-on experience if you are able to access the system or through user guide or functional documents. Some user stories specify features that work in tandem with the features of external systems. In such cases, test cases are designed to validate features which integrate proposed solution with external system.

Sometimes, feature in a user story can function provided it is supported by external system feature. In reality, however, no such feature exists in the external system. Such a discrepancy needs to be identified at an early phase to avoid the business being impacted at a later stage.

Case Story on the Framework Approach
I recently wrote a case study based on practical experience to relate the framework approach with a real-world situation.

This client is the premiere online real estate information service for nearly seventy thousand real estate professionals located across various parts of the United States.

The challenge was that the client wanted to expand its market share by providing better service to homebuyers through real estate agents using a proposed solution.

Userstory1
As an agent, I want to have a screen that allows me to view a customer’s wish list of a property.

Acceptance Criteria:

1. One place in the website that allows a summary view showing important (timely) information

a. Notifications

b. Buyer’s wish list

c. Buyer’s contact information

2. Can choose to show or hide nonactive customers

3. Must be able to see notifications sent to the agent

Userstory2
As a buyer who has a wish list, I want to delete an agent’s access to my wish list.

Acceptance Criteria:

1. Buyer can remove any or all of an agent’s access privileges at any time

Approach:
We will use the systematic approach discussed above to design scenarios.

Understand Your Client’s Business and Its Challenges: We find that the client is in the business of real estate and sees opportunity to expand its base by providing a platform for homebuyers and agents to interact.

Existing Products Help Teams Understand Their Client’s Business: We research the client’s website and communicate with a client representative to understand its existing product and its limitations.

Gist of the Proposed Solution: We study high-level architecture of proposed solution and understand the fitment of solution in client’s IT ecosystem.

Information Exploration: We can see that the users are agents and they want to viewalist of properties that customers are considering buying.

Splitting Acceptance Criteria: The criteria help to achieve the objective with features such as buyer wish list access, buyer contact information, and sorting features for ease of filtering.

In Userstory1, criteria one and two are related to each other, and one and three are related to each other.

Envision a User Interface: Based on our experience, we can visualize that there might be some place on the screen where a buyer's wish list is displayed, and agents can click to access the complete list of properties.

External Systems: Based on our understanding from previous steps, we recognize that the feature in userstory1 & userstory2 is not impacted by external systems.

Interdependency Matrix

Let’s use an example to explain how the interdependency matrix works.

Step 1: Read Userstory1 and Userstory2 and their corresponding acceptance criteria.

Step 2: By now, we have a perception that executing features in Userstory2 impacts features in Userstory1.

Step 3: We will design a matrix to show in detail how each feature of Userstory1 is impacted by Userstory2.

Userstory2 Feature	Is the corresponding feature of Userstory1 impacted by a Userstory2 feature?	Userstory1 Feature	Comments
Buyer can remove any or all agents’ viewer permissions at any time.	Yes	One place in the website that allows agents to view a summary showing important (timely) information a. Notifications	When a buyer removes an agent from his contact list, then any events related to the buyer's wish list shouldn't be informed as notifications to the agent.
	Yes	Agent can view a buyer’s wish list	When a buyer removes an agent from his contact list, the agent should not be able to access the buyer's wish list (authorization denied).
	No	Agent can view a buyer’s contact information	When a buyer removes an agent from his contact list, the agent can continue to maintain the buyer’s info in his contact list.
	No	Agent can choose to show or hide nonactive customers	When a buyer removes an agent from his contact list, the agent can continue to maintain the buyer’s info in his contact list.
	Yes	Agent must be able to see notifications sent to him.	When a buyer removes an agent from his contact list, the agent should be notified that the buyer has removed the agent from his contact list.

Explanation: If a buyer has executed a functionality in Userstory2, corresponding functionalities of Userstory1 are impacted. An impact is denoted using the second column of the table with Yes or No, and how it is impacted is mentioned in the Comments column.

Step 4: Next, we design test scenarios based on each of the impacted functionalities.

We have attempted to design scenarios based on real-time situations in which a buyer and an agent are working independently of each other and any operation by a buyer impacts the agent in some way or another.

The approach discussed here is a systematic way to streamline thought processes by sewing together different pieces scattered across an agile story document. As the number of iterations and user stories in each of iterations keeps changing, the framework will help you understand a holistic view of the proposed solution and design a scenario that considers the appropriate interests.