Agile: User Stories

An Approach for Creating User stories

There are three Agile Principals for creating user stories.

1.     Working software is the primary measure of Progress

2.     Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.

3.     Simplicity-the art of maximizing the amount of work not done is essential.

Simple stories that describe what the users’ world should look like when the story is complete.

Example Stories:

Stories that aren’t creating business value for the customer

Work that we’ve explicitly said isn’t going to count as progress

Story #5 is a bad story. The information we need will only be known when we figure out how we are going to build other parts of the system. We do need to build a database, but we can build it empty and use it as we go with the project. We can’t make it a dependency on all other tasks.

A Story like this is

·       A Prerequisite for

·       A Dependency for

Every other Story

When you have two things, both depend on finishing of each other, that’s a definition of deadlock.

If you write a story from user’s perspective, then you’re on right track. You do need to build a database, but you can do it by part by part based on business user needs during the entire project lifecycle.

Software projects that usually fail à weren’t focused on delivering à actual usable business value to the user on a regular basis

Building the application, the way the user thinks about value:

·       Minimizes risk

Agile Principles

·       The cost of some rework is trivial compared to the benefits it provides

·       Delivering business value sooner rather than later

·       Deliver software frequently

·       Strive for simplicity

How to slice work into user stories

The developer thinks about the application development as a stack

So, for the developer, user story would be like that:

As a

Developer

I want

A service layer

So the

App logic is separated from the GUI.

 Or

As a

Developer

I want

A GUI layer

So the

The user can interact with the system

Having a GUI layer or service layer is good but building stories like this violate our agile principle rules.

We need to build user stories as the user thinks about it. It represents the user ways.

How the user thinks about the software application. They think about a software application, how it is valuable to them.

They think about accounting software application as:

-       Invoices

-       Bills

-       Pay bills

A developer thinks an application as a stack of layers of a cake while user thinks an application as slices of a cake.

If we can build the software it provides value to a customer, we can provide value to a customer earlier in the stage of the project.

The size of a story can change from team to team

If you think a story, which will take a couple of days then divide the story into smaller stories.

Split Stories

-       Login Page (user/guest)

-       Shopping Cart

-       Order (1-800 or online)

-       Pay (Credit Card)

Where are the details?

Details can be found in test cases. For example:

We can write questions to stories or details as conditions of satisfaction and can be stored as test cases. We can write those test cases on the back of a user story card.

·       The product owner’s conditions of satisfaction can be added to a story

·       These are essentially tests

Test Case examples:

-       Verify that a premium member can cancel the same day without a fee.

-       Verify that a non-premium member is charged 10% for a same-day cancellation

-       Verify that an email confirmation is sent

-       Verify that the hotel is notified of any cancellation

Details added in smaller sub-stories:

Techniques can be combined:

·       These approaches are not mutually exclusive

·       Write stories at an appropriate level

·       By the time it’s implemented, each story will have conditions of satisfaction associated with it.

The product backlog iceberg

-       Prioritize the smaller junks to be on the top of the pyramid

-       Items which require more duration, need to be in the bottom of the pyramid

-       Smaller stories on the top and bigger stories on the bottom

Theme:

-       A collection of related user stories

Epic:

-       A large user story

-       Development efforts for an epic are not in hours or days. It will take weeks.

An example

As a VP of Marketing, I want to review the performance of historical promotional campaigns so that I can identify and repeat profitable ones. (Clearly an epic)

Writing Stories

Logging in:

-       See how many user stories you can write about logging in.

-       Examples:

o  As a registered user, I am required to log in so that I can access the system.

o  As a forgetful user, I can request a password reminder so that I can log in if I forget mine

Up Stories:

-       As a chief security officer, I want all user passwords must be minimum 8 characters’ long

Some stories will be “implementation ready” and others will be epics

To be a successful story writer, you will need

-       Creativity within bounding scope

-       A graphical approach like hierarchal

Why User Stories

-       Shift focus from writing to talking

If requirements are written down --> then --> at best she will get what was written NOT the user will get what she wants

 For assistance on creation of user stories and epics for your agile projects backlog, please reach out to me :)