4

I have one user story that is dependent on a technical story:

User story: A user can add a product from the database to his profile

Technical story: Products need to be entered in the database by the developers so that it can serve other stories

I'm trying to follow the INVEST model, so I'm searching for a way to make these two stories independent. However, it seems to me that is not possible. Am I missing something or is it totally fine that the 2 stories above stay dependent?

  • 1
    Why do you have the technical story? Why not just get rid of it, and do the work when it's needed? – Erik Jul 24 '18 at 20:50
  • @Erik I considered it as a technical story because I don't know how to include it in Scrum otherwise, how can I tell my developers to fill up the database if I don't include it in a story. Im new to Scrum, and as far as I understood I can't create tasks out of nowhere. So for me, "filling up the database" should be a story so that I could assign it to developers. How would you suggest I should do ? – nader Jul 25 '18 at 20:28
  • 1
    Why do you want your developers to fill up the database if nobody cares? And if somebody cares, find out who it is and why, and there's your story. – Erik Jul 25 '18 at 21:09
  • yes I understand now, I can write something like "As a user I can access a database containing a lot of products so that I have a large choice to choose from" -> this would be a user story and not a technical story which you have suggested to avoid. Thx for the clarification ! – nader Jul 25 '18 at 21:25
  • 3
    Yep. Better yet, eliminate the technical details of the database entirely and just say "As a user, I want to have a lot of products to chose from". If a database is the way to do that, your developers will set that up. If they have an even better idea, they're free to do that instead. – Erik Jul 25 '18 at 21:26
4

Independence in stories is a bit confusing because of how we think of dependency in programming. Independence in the INVEST model means you can do them separately. In your case, you can add products to the database and then when that is finished, create an interaction where users add products to their profile. Less intuitively, you could do it the other way around, creating the interaction with maybe only one product available in the data, but then later adding a bunch of products which would then be available to add to profiles. These are, in fact, independent. Dependent stories are ones that must move forward together - when one starts, the other start. When one goes to test, the other does too.

Technical Stories

There is a lot of debate on the idea of technical stories, but from my experience, please don't do this. Scrum does not require that we use user stories. In many situations, User Stories offer a great tool.

As a verified purchaser, I want to add products to my profile so that I can get messages when new versions are available.

This user story helps the Product Owner express what user he's talking about, how he imagines the functionality to work, and shares why the user may want to do this. If it's a technical task (or in this case, just some extra work) you can have a generic item like

Data Entry: Add Products

Or, if you really want to use User Stories because you are practicing the habit (which is perfectly fine and commendable), really make it a user. Why does the user want this? For example:

As a verified purchaser, I want to be able to look through a list of all products the company offers and add them to my profile so I don't miss any.

When we dress up non-user stories in the trappings of them, we lose sight of what makes a user story effective. Which leads to the next point:

Wrong and Missing Information in User Stories

Please excuse me for being directly critical here, but since you seem to be working to get the most out of User Stories, this seems worth bringing up.

There are different ways to construct user stories, but as a rule, they should have three pieces of information in them: who, what, and why. You have the what, but the who is really vague and the why is missing. I'd encourage you to include what type of user most benefits from this and why they would want to do this in the first place.

Also, and this may feel nit-picking, but you don't usually want implementation details in your User Stories. At best, it is erroneous (if your team doesn't know to pull data from the database, you have bigger problems) and it could cause confusion (for example, if the company recently switched to a sales system with web services that you should pull the products from).

  • "Independence in the INVEST model means you can do them separately" - may I ask what you mean by "do"? I've always taken 'independence' to relate more to 'potentially releasable increment' rather than 'Developer execution'. – onedaywhen Jul 25 '18 at 9:17
  • @Daniel thank you for the clarification. I"ll go with your suggestion by first creating the interaction with dummy data and then fill up the database. However, what would "filling up the database" represent in Scrum if its not a user story (doesn't bring value to users) nor a technical one (you suggested to avoid) nor an implementation detail (you suggested not to include in user stories)? – nader Jul 25 '18 at 20:19
  • the answer to my Daniel's reply is found in the comments of Erik above – nader Jul 26 '18 at 7:24

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.