Follow kosalanuwan on Twitter
View Kosala Nuwan Perera's profile on LinkedIn

Writing user stories: a practical approach

Let me be clear. Software projects are predictably unpredictable. You cannot solve all the problems in the project plan. It’s good if we can schedule good ideas but people don’t think like this way. People solve problems in unexpected ways. This is where good ideas come from. Many are called “Ahaa Thoughts”.

Explaining things are easy. Documenting it is the hardest part, not only that, many devs hate this part, in a software development process. We could only interpret around 50% of "Ahaa Thoughts" into "words".

Writing user stories is not a hard task. Once you master it you can say:

"Documentation in Development processes was my Unicorn, and now it is my bitch"


"Writing user stories was my Unicorn, and now it is my bitch"

As a good citizen, a Business Analyst or a Product Owner could use a template/standard. I use something like this:

User Story

Name: Customer List
As a: User
I want: Interactive Customer List
So that: I can change the details of my customer
Size: XS, S, M, L, XL

This user story comes from my Product Backlog List. It is a White Note on my wall. Things I can do about this story are called Story Points, that explains further about the story. A story point is a Yellow Note on my White Note. I write it like this:

Acceptance Criteria/Story Points

Name: Delete an address
Given: The customer is in an editable state
When: The remove address button is pressed
Then: The address will be removed from the list
And: The change will persist after a refresh

Name: Add an address
When: The application is loaded
Then: A list containing customer addresses will be displayed
And: The name of each customer will be displayed with an image next to it

To reduce the number of documents that we have to maintain in a development process, I use these User Stories and Acceptance Criteria for Testing. A Bugs is reported under a White Note or a specific Yellow Note, if not, a separate Defects Backlog List (parallel to my Product Backlog List).

For more readings;

Beyond Functional Requirements On Agile Projects by Scott W. Ambler
Complex Requirements On an Agile Project by Scott W. Ambler
Introduction to User Stories by Ambysoft
User Interface Prototypes by Ambysoft


Anonymous said...

Interesting! How do you add the none functional requirements in to the backlog?

/KP said...

Hi Ano - Sorry about the delayed response. I do not have a perfect answer for your query.

Typically, most NFRs are shared across many user stories. For instance, Performance, Security, Scalability, Supportability, Portability etc.

Now, a very common approach is to identify these NFRs as Constraints/Confirmations and add into AC/SP section when needed. Problem here is that you might end up with huge User Stories in mid-sprints.

The easiest option is to write them as User Stories, share them across Other User Stories and Story Points, perhaps list them in the Scrum Board.

However, when you bring these Constraints/Confirmations into your User Stories, it will be difficult to estimate and even to draw the line for Definition of Done.

MORE: I have updated the post, I suggest you read articles linked in the post.

Post a Comment