CODEWITHSUNDEEP
databasedatabase-designfrontendbackenduser-stories
DrD4rk
DrD4rk

Reputation: 57

User Story - Database design

I need to build a product that will have a database on the back end to store and retrieve data.

I just started gathering the user stories from my stakeholders and I am stuck...

If I have a Project Leader who has one user story like: "As a project leader, I want to be able to see and modify the scope of my project so that I make sure my project is up to date"

This user story would require I had created the database and have a table before that having the data in the table.

Should I collect all the user stories and add the database component on the acceptance criteria?

Should I create user stories only for the back end and some for the front end?

I'm not sure how to separate or make them work together.

Upvotes: 0

Views: 10688

Answers (1)

Mike
Mike

Reputation: 550

The idea behind SCRUM is that the architecture / design will emerge as you develop. With this in mind you still need the product backlog to reflect what will the product be. So somewhere in the backlog there should be a user story like... "As a user, I want an application that I can use the manage my projects". That story is rather large (epic) level. So that has to be broken out into smaller stories (like the "... the application must have ability x"). If that is indeed the user story, then another sub epic (still large needs breaking out) story would be... "As an application developer (notice the context change here), I need a database to store my Project application data". Then that story gets broken out for the person making db scripts (assuming you are creating the application database first, some applications are code first and ORM generates database schema). The main point here is that you start large and break it down until you get a full backlog with very small stories. Then you know you have a full backlog (groomed backlog) and you are ready to start planning your sprints.

Upvotes: 4

Related Questions