Creating User Stories for Features in an Agile Development Project

Share on FacebookTweet about this on TwitterShare on LinkedIn

Share on FacebookTweet about this on TwitterShare on LinkedIn

A team member of a project one of our analysts had previously worked on wrote the word “Breadcrumbs” on a Post-it® and subsequently added it to the Project Backlog. This single word was the sum total content of what was supposed to be a User Story.

As the Product Owner, I was charged with grooming and maintaining this Backlog, flushing out and refining its User Stories, and ranking them by their relative business importance. As I’m relatively new to Agile, I found myself pulling from my 40+ years of working with new technological or procedural “knights in shining armor”. As an industry, we are always seeking new ways to solve problems, but the constants are the underlying raw materials –we  IT practitioners have not changed. To allow myself to fulfill my role of Product Owner in this new construct of Agile, I drew upon my experience with User Stories to help turn the single word “breadcrumbs” into something of value.



A Case in Point: “Breadcrumbs”

So how does one turn “Breadcrumbs into something actionable, implementable, and testable? The Book of Agile says that good User Stories should focus on the user, facilitate a conversation, be simple and concise, have actionable acceptance criteria, and be testable.

To focus on the user, “Breadcrumbs” should tell a story about the person wanting to use them.  The story should be written from the user’s perspective and employ personas or actors such as “user” “manager” or “buyer”; and should describe what action the actor needs to perform and why. To maintain consistency and convey the same focus, the story should follow a simple, consistent, concise format, such as:

“As an , I want so that .”

Applying this user story template, “Breadcrumbs” became:

“As a new user, I want “breadcrumbs” on each screen so that I know where I am and how I got there.”

Now that we have expressed the, “what and why” of our user story, how does the project team know when they have achieved their goal? How can we demonstrate that the user story has been successfully achieved? To accomplish this, we still need actionable, testable Acceptance Criteria.

Applying these guidelines to “Breadcrumbs,” we might arrive at the following two Acceptance Criteria:

AC 1: I can see a breadcrumbs trail on the current screen page which shows me the navigation path from the Home page to where I am.¶
AC 2: I can click on a segment of the breadcrumbs trail and I will be taken to the screen page that corresponds to that breadcrumb trail segment.¶

These Acceptance Criteria are readily actionable and testable, with Test Cases easily written to verify each of these conditions of satisfaction:

TC 1: From the Home page, click on the Reports menu option, then the Dashboard entry. Expected Results: the Dashboard page displays with breadcrumb trail: Home>Reports>Dashboard.

TC 2: From the Dashboard page, click on the ‘Reports’ segment of the Home>Reports>Dashboard breadcrumb trail. Expected Results: the Reports menu page displays, with its associated breadcrumb Home>Reports.”

We have gone from “Breadcrumbs” on a Post-it® to a more mature, actionable, testable User Story.

Download our Agile eBook