Designing Scenarios for Agile Stories


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


Buyer can remove any or all agents’ viewer permissions at any time.


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.


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).


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.


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.


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.

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.

User Comments

robert woods's picture

With all due respect....this sounds a little like "We Didn't Have A Good Product Owner So We Found A Way To Get Around Having One At All". Its admirable that you took the time to dig deeply into the products, offerings and aspects of the company and stories, but it all adds up to making only slightly more educated assumptions in the long run and creating a culture within the company that a PO isn't really needed if we create higher levels of expectations on the development teams. There still remained a high level of risk of creating the wrong thing because the voice of the customer was not involved from the business side. The answer lies in gaining the the [proper education and alignment as opposed to moving forward semi-blind.

February 28, 2014 - 10:35am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.