Creating user stories from a requirements specification enables a development team to prioritise tasks and have things organised in a more structured and traceable way. Just as importantly, they can be arranged on a ‘story board’ as a way of communicating the current state of a project and the workload. Often I see this done with post-it notes on a whiteboard:
A user story usually is a variation on the following template statement:
As a… [user/application/consumer]
I need/want/expect to… [insert action here]
So that… [insert goal or objective here]
As an example, one user story I wrote the other day went something like:
'As an auditing application, I want to call the GetDepartmentNamesCodes() method from the API, so that I get a list of department names and department codes.'
Sometimes we find ‘acceptance criteria’ attached to user stories. These are lists of things to determine when a feature can be considered finished. For example:
* The application/user is able to call the API method
* The API method returns the correct data.
User Stories in Team Foundation Server
The following example is loosely based on a current real-life project I’m working on. While it has only two user stories, both features will consist of multiple components, and there’s a good chance they’ll have a load of artefacts associated with them later on. If the test analysts find defects, we want to have the test scripts and results traceable to whichever features.
Extracting a list of user stories from the requirements specification is the first step.
Generally each user story is going to be implemented by a product feature. For example, a user wants to get a list of department names and department codes, and the feature could be an API to fetch that data. To add a feature, open the relevant user story, and create a feature as a ‘New linked work item‘.
After this is done for all the user stories, we’ll have a ‘backlog’ of features we can trace back to them. The story board here has a similar format to the physical white board:
The second tool I came across isn’t an Application Lifecycle Management thing like TFS, but it can still be used by relatively small development teams for organizing features, user stories and related artefacts. I use this mainly to organise tasks rather than user stories.
The main interface of Trello is a ‘story board’ similar in layout to the TFS board. Each column is a ‘list’, and each list can contain a ‘card’ that represents a work item or user story. Here I’ve created three lists: Backlog, In Progress and Complete.
As with TFS, a card can be dragged and dropped across lists.
As it happens, you can also attach things like screenshots, test scripts and source files to each Card, so it does provide for some level of traceability.
Listed as a ‘Power Up’, the Calendar is an optional feature that must be added manually. Clicking on a date in the calendar enables a Card to be added, and a work item to be added within it.