Evaluating User Story Readiness

An often-heard conversation during retrospectives:

Facilitator:  So, what could have been better?
Team Member:  The user stories were too big.
Product Owner:  I’m sorry.  I certainly want to improve that.  How could I improve that?
Team Member (after some thought):  I’m not sure, but they need to be smaller to get them done in a sprint.

The conversation may continue for some time. 

The challenge is, even if the team has a reasonable Definition of Ready for each user story, they don’t seem to have an objective way to expose ways in which a user story could be sub-divided and still provide business value.

The following are five items which can be added to any Definition of User Story Readiness to help ensure each user story is highly cohesive, and testing complexity is considered.

 

1. Specific User Story Phrase:  One indicator of a user story which has low cohesion, is when they lack a proper user-story phrase, or the phrase is ambiguous (e.g. “Create a ‘Log In’ page”, or “As somebody, I want a ‘Log In’ page, so that I can use the site”).  When a user story is highly cohesive it will have a very specific user-story phrase (e.g. “As a customer, I want a ‘Log In’ page, so I am assured only I have access to my account”, or “As a Marketing Executive, I want user authorization, so that we can present appropriate content to each user”).

2. Testable Acceptance Criteria:  Too often acceptance criteria are written along the lines of “It Works” (though in other words).  It is critical for each acceptance criteria to be testable, something for which you can express clearly a specific scenario, a specific action, and a specific expected result.  A helpful way to express this is by using BDD (Gherkin) language:  Given [a state, or data scenario], When [an action occurs or is taken], Then [a specific result occurs] (e.g. Given valid credentials for an existing user, When on the ‘Log In’ page the credentials are entered and the ‘Log In’ button clicked, Then the ‘Landing’ page is displayed).

3. Cohesive Acceptance Criteria:  The “Then” of each acceptance criterium describes the “Test Subject”.  For example:  In “Then the ‘Landing’ page is displayed”, the ‘Landing’ page is the test subject.  In “Then the user’s name is displayed in the ‘Landing’ page header”, the ‘Landing’ page is the test subject.  In “Then an auth token is generated by the auth server”, the auth token is the test subject.  Acceptance criteria are considered highly cohesive when all have the same test subject.  A way to improve cohesion is to extract acceptance criteria for the same test subject to a different user story.

4. Functional Test Plan:  The majority of functional tests can be extrapolated from each acceptance criterium.  The assumption can be made that there are multiple ‘Given’ states in which the ‘When’ action should produce the ‘Then’ result.  By moving the ‘Given’ statement to the end of the acceptance criterium (written in BDD language), every scenario which should produce the same result can be listed.

5. Exploratory Test Plan:  Assuming all functional tests are automated, manual testers (QAs, BAs, etc.) can now practice Exploratory Testing (not “ad hoc”, but a formal approach like Session-based Exploratory Testing), finding defects much more difficult (if not impossible) for computers to feasibly discover.

 

 

Craig A. Stockton | QA Automation Architect - Continuous Testing M 253.241.1598 | cstockto@TEKsystems.com 1601 5th Avenue, Suite #800, Seattle, WA 98101

TEKsystems. Experience the power of real partnership.

 

 

This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic mail or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply e-mail so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you