Covering many users

I’m a bit stuck.

I am writing some user stories for our reseller platform and am now starting to think that a problem with them is that unless I write a 100 stories I might end up missing vital functionality. We have sales people, tech support people, dedicated operators and accounts people all logging in to our system to do different taks.

Have you come across this issue before and how did you deal with it

Do the different people log into different versions of the app?

For example we produce 1 product but there are different version - payer, manager, caterer, whiteboard,

For each of those we would then have a number of different user stories, so in total for the product there would be maybe 20 user stories

Could you also look at combining some stories e.g. instead of 3 stories:

  • 25 year old single male
  • blind male
  • single dad

You could have a 25 year old blind single dad?

1 Like

I think you may be confusing what I am considering to be stories and personas.

I have about 6 personas which seems perfectly manageable but then each of them has perhaps 3 or more stories aka Why am I here today. I guess goals or tasks would be a better name I can see how story could be taken to mean biography. So I am wondering about how many of these is a reasonable number and what do you do about functionality that you know is needed but falls between the gaps of your stories.

It is an existing platform that is being rebuilt rather than an entirely new one.

Ah ok, that makes sense.

In my opinion you have as many stories as makes sense. If the software is large and has lots of features you’ll have more stories. Maybe it’s worth looking at the main use casesand ignoring some of the smaller less used cases to start with?

1 Like

Thanks, that sounds like a good way to plan it.

The back end devs here are going to redo a lot of our APIs and then put my designs over the to of that so I guess I can structure my process how I want.