I have written various user stories that describe functionality at a pretty high-level. For example:
As an analyst, I want to view the current share price, so that I have quick access to an up-to-date valuation of stock across the Euronext, London and New York stock exchanges.
This requirement is based on existing functionality that is being re-developed in a new version of some software. I can see from the existing implementation that the actual information displayed includes a lot of extra data such as different classes or shares, different timescales of graphs etc.
I think it is impractical to capture all the functionality in the current implementation. So I have two questions:
-
How do I decide an appropriate level of detail for the requirement that is basically ‘do what the current piece of functionality does’.
-
Is there some structured approach of accompanying the user story with more information? At the moment, I feel this would be the job of wireframes.
1
As an analyst, I want to view the current share price, so that I have quick access to an up-to-date valuation of stock across the Euronext, London and New York stock exchanges
As written, this has no business value: you don’t say what the analyst does with the data, just that s/he can access it. Here’s how I’d rewrite the story to add value (which may not be the value that your analyst actually wants):
As an analyst, I want to view the current share price across the Euronext, London and New York stock exchanges, so that I can make trades to arbitrage differences in the price.
The first part of the story says what the analyst wants, the second gives the business value. In your original formulation, both parts said what the analyst wanted, but not why.
And the relevance to your question: the level of detail should give both what and why, but not how (the how might be covered by wireframes).
How do I decide an appropriate level of detail for the requirement that is basically ‘do what the current piece of functionality does’.
You should be wary of doing this. This requirement implies that the functionality needs to be maintained, rather than the business need be satisfied. Often times this can lead to bad decisions being carried forward, or limit the innovation that your team might be able to provide the business.
I would be inclined to go with this high level story, and then provide more stories around the other use cases that the business has. Granularity has its advantages.