Designing Scenarios for Agile Stories


 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.

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

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

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.