Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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:

  1. How do I decide an appropriate level of detail for the requirement that is basically 'do what the current piece of functionality does'.

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

share|improve this question

migrated from stackoverflow.com Jul 23 '12 at 20:36

This question came from our site for professional and enthusiast programmers.

    
You need to describe the functionality even if it's "do what we do now." Not everyone will have access to what we do now, especially down the road. –  Loren Pechtel Jul 23 '12 at 21:22
add comment

2 Answers

up vote 2 down vote accepted

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.