The Building of Yeww: A WebRTC ProjectUser Stories

Posted on September 10, 2016 at 3:37 PM by Lynn Walker

In agile development, a user story represents business value that can be expressed as a small task, and implemented within one iteration of the development cycle (sprint).

A Good User Story

The user story should be specific about what action takes place and the expected result. The story should be deliberately vague about details, as these will defined by the developer, possibly in a communications loop with the customer for clarification of intent. The agile philosophy believes too much time is wasted with premature documentation. A good user story should focus on capturing the essence of the task without all of the explicit details. The language should be business like, not technical.

First User Story

As an example, I will propose our first user story for the yeww project:

A VISITOR ENTERS VALID USERNAME/PASSWORD CREDENTIALS AND IS SUCCESSFULLY LOGGED IN

This user story is describing a successful login process. Notice that it doesn’t tell you what the input fields are called or their other attributes. It doesn’t mention the appearance of the login page. It doesn’t discuss validation or where the user is redirected upon successful login. It does specifically mention username and password as the login credentials. That means the rest of the design will be dependent on username/password as the login credentials. Everything else will be defined as needed and this will allow the rest of the design to evolve fluidly.

Beware of TMI (too much information)

Agile means successfully responding to demands for change. Agile development anticipates change will occur over the period of development, and leaves room for it, by not over-defining in the beginning. If you already have a design and the screen elements need to appear in the designed position, then the user story should refer to that specific detail. Yeww has not yet established a design for the site, so our user stories don’t refer to the display specifics. Agile consists of a lot of “just-in-time” design decisions in comparison to the rigidly pre-defined approach of waterfall development.

Feature Definition

To capture the full login feature, at least one more user story is needed:

A VISITOR ENTERS INVALID USERNAME/PASSWORD CREDENTIALS AND AN ERROR MESSAGE IS DISPLAYED

In fact, for yeww, we need a few more user stories to complete our intentions for the login feature:

A VISITOR ONLY HAS ACCESS TO THE MARKETING PAGES UNTIL THEY SUCCESSFULLY LOGIN

ONCE LOGGED IN, A USER REMAINS LOGGED IN UNTIL THEY LOG OUT OR CLOSE THE SESSION

ONCE LOGGED IN, THE USER’S USERNAME APPEARS AS A LINK TO AN ACCOUNT MENU

ONCE LOGGED IN, THE LOGOUT MENU OPTION IS DISPLAYED

It takes this collection of six user stories to adequately define the login feature we want to design.

Writing User Stories

Ideally a story gathering party is hosted, with customers and developers contributing, compiling a list of one to four dozen core user stories that define the work for the first weeks or months of the project.

As the project progresses you will continue to write more user stories, most likely at the beginning of a sprint. As the remaining pieces of the developing project are known they become the next user stories.

Try to make stories that can be completed within a single sprint, though you may find that some epics must be handled across multiple sprints. In that case, the effort must still be sub-divided.

Yeww's Project's User Stories (initial)

I’m breaking the project into six features plus navigation, with user stories defined per feature. For login I am creating all of the user stories now, for the other five features I will just cover one main task. We will revisit user stories for the other features as we approach the time to develop them. I also defined user stories common to the application.

Login

A VISITOR ENTERS VALID USERNAME/PASSWORD CREDENTIALS AND IS SUCCESSFULLY LOGGED IN

A VISITOR ENTERS INVALID USERNAME/PASSWORD CREDENTIALS AND AN ERROR MESSAGE IS DISPLAYED

A VISITOR ONLY HAS ACCESS TO THE MARKETING PAGES UNTIL THEY SUCCESSFULLY LOGIN

ONCE LOGGED IN, A USER REMAINS LOGGED IN UNTIL THEY LOG OUT OR CLOSE THE SESSION

ONCE LOGGED IN, THE USER’S USERNAME APPEARS AS A LINK TO AN ACCOUNT MENU

ONCE LOGGED IN, THE LOGOUT MENU OPTION IS DISPLAYED

Register

A VISITOR ENTERS VALID PERSONAL INFORMATION TO REGISTER AN ACCOUNT

Navigation

A USER INITIATES EACH FEATURE BY PRESSING THE APPROPRIATE NAVIGATION LINK

Profile

A USER CAN MANAGE AND SAVE THEIR ACCOUNT PERSONAL INFORMATION

Search

A USER SEARCHES FOR OTHER USERS BASED ON SELECTABLE CRITERIA AND BROWSES THE RESULTS

IM

A USER HAS A TEXT CHAT SESSION WITH ANOTHER USER

Video Chat

A USER HAS A VIDEO CHAT SESSION WITH ANOTHER USER

General

ALL VISITOR AND GUEST DATA WILL BE STORED SECURELY, IF STORED

A VISITOR OR GUEST WILL BE ABLE TO VIEW AND USE THE SITE ON ALL DEVICES

A VISITOR OR GUEST WILL EXPERIENCE REAL-TIME RESPONSIVE INTERACTION WITH THE APP ONCE LOADED


Previous lesson

Next lesson

Previous lesson

Next lesson