How to Write a User Story

So WHAT exactly is this "user story" MondayCall speaks of?

Ideally, written primarily by YOU (the client), user stories are short, simple descriptions that focus on the actual requirement rather than talking about them. User stories are told from the perspective of the user who needs the new capability and not in "tech speak".

MondayCall relies on these user stories to understand how and why a new functionality should behave and perform.

And WHY do I need to care?

Since you, our client, will be the end user of this system, the more you convey to us

what you need
when you need the functionality (how often, for how long)
where (mobile, desktop)
how you use the capability
why you need the feature, function

the more we can design the best suited solution.

So, in the Agile process, user stories are the standardized "device" to capture these business requirements. It is often a best practice for the Customer to write many if not most of the User Stories as nobody knows your requirements better than you do.

And HOW do I write a one?

User stories are brief and written in plain language that does not require technical or deep Salesforce knowledge. The basic structure of a user story is...

As a <TYPE OF USER> , I want <DESIRED GOAL> so that <REASON>.

Examples of TYPE OF USER include

End-user operators, of course! But don't forget...
Managers who interact with the data
Executives who track information in reports
Other downstream consumers of the information (e.g. finance, order entry, etc.)
Portal/community users
Engineers/Project Managers who want to track technical project requirements

Examples of USER STORIES:

"As an inside sales rep, I want to see my call list and query by oldest first so that I can make sure my oldest call is not greater than 1 week."

"As a renewals specialist, I want to receive an alert for any contract expiring within 30 and 60 days so that I may contact them about an extension."

"As a Sales manager, I want to see my region pipeline of deals by sales rep so that I can use this report as the basis for my weekly sales call."

"As a Project Developer I want to have the Salesforce Sandbox Refreshed so that I can develop without colliding with other developers’ efforts."

6 Key Things to Consider When Crafting User Stories:

NDEPENDENT: No overlap or confusion with other user stories. Be able to develop in any sequence.

EGOTIABLE: Keep it flexible

ALUABLE: User Stories must meet criteria for Minimum Viable Product (MVP) or else it’s not worth adding

STIMABLE: Each User Story must be clear and small enough to be estimated and prioritized

MALL: Should start first with larger User Stories (called Epics) and then break it down to smaller functional chunks that fit within a sprint

ESTABLE: User Stories are easily transferable to test cases and should be used during testing

BACK: What to Expect

NEXT: Keeping Within Budget

Report abuse