What: ‘User Stories’ is intended to break business requirements into their most basic unit, stating what is needed, by an actor, in other for an action to be completed.
They generally follow the format below:
<user> needs (MUST, COULD, WOULD) to be able to <Action> because <Reason>
Why: Useful mostly in (pseudo-)agile delivery environments where delivery is planned to be in short iterative bursts, in which each iteration delivers usable features of a solution being delivered. In these situations, user stories will serve the purpose of atomising each required feature and sub-feature where applicable and enable the team (the owner, the business analyst, the development team, the test team and onlookers) to prioritise these for delivery using a preferred method, including but not limited to Kanban.
User stories, can easily replace complex user journeys and use case documentations, remove the complexity of determining the sufficient level of detail of a business requirement and often solves the problem of ownership.
When: The best time to document user stories for a project or product is soon after stakeholders have been identified and usually before the first line of code is written or other executionary step is taken.
How: There isn’t a silver bullet and each team should come up with an approach that best suits them – this can be arrived at following several experimentation effort. However, in addition to the general format provided above, teams MUST have the liberty to:
- Prioritise each user story for delivery;
- Bundle features together for delivery following some logic -e.g. similar stories which if delivered together can deliver a more useable function or can meet an immediate business need;
- Carry all stakeholders along – communicate plans, changes, progress, challenges per user story;
Note this is part of a series of writings that are geared towards my planned 2019 book: The BA Book. I am deliberately grouping them together here as first drafts as that is what most of them are. Doing this helps me stay accountable as well as gain early feedback from stakeholders.
Your comments and feedback on this early thoughts will be appreciated and applied towards further shaping the research that will go into the writing the book.
Cover Image credit: http://www.agilemodeling.com/artifacts/userStory.htm
