Tags

, , , , ,

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:

int-app-story-board

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.

There are two freely-available online tools that can extend the story board method to provide traceability throughout the development and testing process: Microsoft’s Team Services and Trello.

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.

tfs-user-story-list

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‘.

tfs-select-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:

tfs-story-board

Trello
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.

trello-main-board

As with TFS, a card can be dragged and dropped across lists.

trello-moving-card

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.

trello-attached-files

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.

Advertisements