-1

Would like to ask on how would you write user stories where your initial set of tasks is to analyze or gather requirements.

A little background, let's say a client has a legacy application where they would like to have it converted to an online app. The legacy app uses solely excel sheets + macros. Now, when writing user stories, how would your write the following?

  • Gathering of existing sample data, based on this, the existing physical excel files with correspoding documentation
  • Analysis of the excel files and documentation to derive business rules and logic (what are the possible values of this excel field? etc, etc)
    • analysis regarding relationship of data, normzalition forms, etc

Can I do something like - As a business analyst, i would like to yaddi-yadda?

it doesnt sound right...

Can you guys help me by stating a few examples of agile user stories for requirements gathering? Thank you.

user1465073
  • 315
  • 8
  • 22
  • 4
    I'm voting to close this question as off-topic because it's not about programming. Project management is off-topic on SO. – BDL Aug 17 '17 at 09:46

3 Answers3

1

You should not write stories to write stories. There is no sense in building a backlog of tasks, because that's never the intent of user stories.

So start with a very quick, very high level description of the intent of the product/system, that should give you enough to start the work from, now refine each of high level descriptions into sets of stories.

There should be no need to create stories to track this work, the state of the backlog itself should be enough indication.

Since, with user stories, you will start the work when not everything is clear (yet) part of the work of actually building will be to extract the exact business rules, or analyze the excel files to ensure that the right test cases will be built. This is not required to build the backlog, as the level of detail will be much to deep.

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
0

No need to write user stories for this kind of tasks, but I will suggest you to create tasks for each group of work. May one be analysis tasks per module/functionality of existing system.

Once analysis tasks finished, you can go ahead and start writing user stories base on work identified.

Priyang
  • 376
  • 2
  • 7
0

"A little background, let's say a client has a legacy application where they would like to have it converted to an online app. The legacy app uses solely excel sheets + macros."

OK, so why does the client want the legacy application to be an online application? For example:

"As a user I want to be able to access the ABC application online rather than having to install it locally because that allows me to work in a more productive way"

Now that sounds like a mighty big story (or even an epic). So perhaps the next stage is to break it down. Perhaps a time-boxed spike to investigate the existing application and derive some key features. These can then be converted in to stories, for example:

"As a user I want to be able to upload my data set so that it can be processed"

"As a user I want to be able to run an XYZ analysis on the data set so that I can work out the factor X value"

At this stage the team can make a start and work towards producing the first shippable product. Engaging with the customer to make sure that what is being built meets their requirements (rather than simply replicates the previous application).

The intention would be to produce the most valuable features first and to make them in to a workable product at the earliest possible opportunity. This is preferable to spending lots of time extracting requirements from the legacy application and so having a long time before the customer gets to see anything.

Barnaby Golden
  • 4,176
  • 1
  • 23
  • 28