Is it ok to define a user story that has no real business value without another story?

Question

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.

Answer 1

The best approach i to keep the stories separate.

The two stories are not really that dependent on each other that they violate the I from INVEST. US2 may appear to depend on US1, but in reality you don't need US1 to demonstrate US2.
To demonstrate that users can use a "card view" to browse the database only requires that some form of card view is available. It is not required that this card view can be created using the application, only that it somehow exists. Thus you can demonstrate US2 with one or two hard-coded card views and inform the stakeholders that there is another story underway to allow a user to create them.

It is quite common that a story on its own only brings a very marginal benefit to the product and that the real benefit comes from a combination of stories. This is most visible when developing a new product, but also happens when extending an existing product.
If you were to combine stories until they provide enough business value on their own, you might just as well go back to waterfall development, as the story would cover the entire product development.

You also shouldn't be fooled by the "delivery" you make at the end of a sprint. You deliver a potentially shippable product. This doesn't mean that it will be shipped to customers, but only this: If the Product Owner finds that the product has sufficient business value to actually ship, then he can ship it without additional work from the development team being needed.
A product with only one of two related stories (where both stories are needed to add the real value) most likely won't be shipped in that form.

Answer 2

Split stories into small vertical slices

The Waterfall approach is to slice the application into horizontal (functional or architectural) layers. In Agile/Scrum we try to deliver small slices of end-user value by vertical slices across different architecture layers. See the example here showing vertical slices across three architecture layers:

1. Client application
2. Server
3. Database

Scrum advocates doing all functional work needed to deliver end-user value within the same story. For example, you may have design of the user interface, front-end coding, back-end database design, back-end coding and testing all to be done as part of one story.

You can read this article for different ways of slicing a large user story into smaller vertical slices. For your example, you can probably use Pattern #8. You can write one story that allows the user to view the data. You can write other stories for creating, editing and deleting data.

Answer 3

I'm a little unclear on your question. If you are writing this user story for a team building an application in Microsoft Access, then US 1 doesn't exist, as it's the work that is done by the team to complete US 2. In this case, the deliverable is that the user can see the data in the new view.

However, if you are suggesting that you are writing user stories for the team creating Microsoft Access and you want to have the functionality to 1) design a card view in the IDE and 2) have the card view render a certain way to users of that application, then you have a much more elaborate situation. In this case, you do, in fact, have two user stories that are independent.

This is a pretty common misinterpretation between something being potentially shippable and if you chose to release it. If you were to do US1 first, you might think that it has no value if users can't see the rendered version, but maybe you have a big developer conference next week and you're handing out a developer preview version of the software. Being able to show the design of the card view during a code session could be unbelievably valuable. Or, to look at it the other way, US2 seems like it needs US1 to be any use, but what if you can import projects from a previous version. Now US2 allows people to import a project that uses card view from an old version and view it properly, even if they can't yet change the design.

Of course, as you said, you may choose to wait and release them both at the same time, but that's a business call. No reason those aren't valuable by themselves.

Answer 4

This article suggests that two such stories should be grouped together into an Epic, where the Epic collectively has business value, but its constituent stories don't. Ideally you strive for each story to have business value, but when a story is too big and it can't be split without making individual stories which have little or no business value by themselves, you can make it an Epic and split it into stories. That's one perspective and I don't necessarily agree with it, but it may be pragmatically necessary in some cases.

Answer 5

US2 is dependent on US1 but it does not break the I in INVEST as long as you do not attempt to develop both US1 and US2 during the same iteration. The I in invest is meant to protect against dependencies within the iteration that would prevent the team from making iteration commitments. There are very few user stories that are truly independent, and trying to force stories to be truly independent would lead to a lot of epic level work items that wouldn't fit into small iterations.

US1 does arguably bring value to the developer of the card. It does not bring any value to the consumer of the card (US2). I'd say splitting between US1 and US2 is a valid approach to deliver incremental value to the customer, since the customer should recognize value in the developer being able to define the card as the first step towards allowing the user to consume the card.

Answer 6

According to my understanding of your question i can say:

end user is interested in features, only the features, so the good estimation process will produces one feature as a collection of user stories, "We eat the cake from top to bottom not from right to left".

i think your the two user stories are independent , you have to label every thing that does not related to an end user as acceptance criteria, and it is the scrum team responsibility to select the development technique, you can add an internal team task that link data to the design , this task is not visible or valuable and it does not interested end user at all.

if you merge your two user stories to one like:"as an end user, make sure that i can view data via custom card view", do you think that it is really a big story and exceeds the sprint time frame "timed by 2-4 weeks".

your scrum team for that user story should define multiple tasks like:

1- design the form designer. 2- develop data providers classes for each data view component. . . . testing team with developers will check that an end user can design card view and link it to back-end data.

please, clarify me if i I misunderstood what you asked.

Answer 7

Short Answer - You don't need two stories. User stories are always written from the perspective of the end user. Associate different technical tasks to this story that cover tasks on the DB, UI, or business logic layers.

For additional guidance on breaking out user stories and how to approach them, see How to make user stories independent in multi-discipline teams

Sorry for format/grammar/typos I am on mobile and will clean this up later.