Question

I am working on a project that requires the use of user stories and part of the project is to perform authentication against an ASP.NET database. From reading up on this a story would follow a similar pattern of:

As a un-registered user I want to register with the application so that an account is created......and so on.

From a "acceptance" point of view I see this as a back-end part that does the work and then the UI that the user can interact with. But there are other, non-related, projects that can use the same functionality, so this will be part of a shared framework/library.

With the code going into a library that doesn't have a front-end how should the user-stories be written? Should the stories still be written from the point of an end-user even though the user will not use the functionality directly?

Was it helpful?

Solution

Don't get fixated into fitting every user story into a template. The "end-user" view of the story is there to give clarity to the developers to visualise the usage of the feature, and in the process understand the context to implement the story better. It is also there to help you split stories vertically, and avoid writing stories like "migrate the database".

If you have those two in mind, then write the stories that make sense for your situation. In your case, I would consider the calling application as the end-user, and write the story as "As an application, I would like to create an account, so that..". To me that gives the correct context that I need to keep in mind when implementing the story.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top