I'm struggling to find the best way to use scrum and user stories on the following case:
To explain the situation let's imagine we are developping Microsoft-Access.
In microsoft access you can design an application and then you can run the application.
- Designing the application consist of defining the data model, the different ui views to access it (forms, tables...).
- Running the application allows to browse and create data using the specified views.
So in ms-access the end users could be splitted in 2 roles:
- app designer: the users that design the application elements.
- app user: the users that connect to an application and uses it to browse and create data.
Let's say that ms-access product owner wants to add the support of card views in addition to existing table views and form views. This feature could be materialized as 2 user stories: * US1: As an app designer I want to be able to design card view for an application * US2: As an app user I want to be able to browse data using the card view if one as been designed instead of using the table view
The problems I see with having 2 separate stories is that:
- US2 depends on US1 to be achievable (this breaks the I of INVEST right ?).
- US1 without US2 does not bring any real business value. Releasing the product with only US1 would provide the capability to design card views that are useless without US2.
The problems I see with merging them together is that:
- The merged user story would be targeting 2 end user roles which is a bad practice
- It would also make stories too large to be easily estimatable in most cases.
What is the best approach to follow in such case.