Introduction
In software development, agile practices approach discovering requirements and developing solutions through the collaborative effort of self-organizing and cross-functional teams and their customer/end user.
After initial discovery with customer we have a business requirement specification (BRS). The BRS however is very high level when it comes to implementation details. Ideally it should be followed by a solution design document containing entity relationships (ERD), sequence diagrams and user stories/Epics.
Why Do we need User Stories?
In agile/hybrid world work break down structure for a developer could equate to user stories. After getting in trouble a few times on projects with difficult customers its my observation that User Story helps curb scope creep and client's possible whimsical non-acceptance of delivered work. It also helps in collaboration and spot dependencies early on. Any change of resource mid-way thru a project could be very challenging to handle in absence of process around managing the tangible work items/ user stories.
Atlassian and Rally have been the pioneers as Agile coaches and we should aim to benefit out their experiences. Some key guidelines published by Atlassian on writing a user story can be read here https://www.atlassian.com/agile/project-management/user-stories
How to write User stories?
User stories are often expressed in a simple sentence, structured as follows:
“As a [persona], I [want to], [so that].”
Breaking this down:
"As a [persona]": Who are we building this for? We’re not just after a job title, we’re after the persona of the person.
“Wants to”: Here we’re describing their intent — not the features they use. What is it they’re actually trying to achieve? This statement should be implementation free — if you’re describing any part of the UI and not what the user goal is you're missing the point.
“So that”: how does their immediate desire to do something this fit into their bigger picture? What’s the overall benefit they’re trying to achieve? What is the big problem that needs solving?
Definition of Done
The other important aspect of user story is acceptance. To ensure that a user story solves the actual customer requirement we need to test it against acceptance criteria. The definition of done of a user story is tied to this acceptance criteria. Only when the story tests positively against the acceptance criteria it is suggested as "Done".
This acceptance criteria should ideally be written by the customer. It helps better involvement from customer which you customers would be thankful for later especially in Salesforce implementation when customers mostly own the solution post implementation. In absence of commitment/availability from customer on writing acceptance criteria we need to at least get them to formally approve it.
The goal here is the breakdown the problem statement into measurable units of work which helps you set the team for success as its easier to accomplish several smaller goals than achieve ambitious targets.
Comments