Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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?
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).
