Designing Scenarios for Agile Stories


The needs 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. Read on to learn how to design scenarios for agile stories using a structured framework.

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.

Fig 1

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.

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.