User stories for BE functionalities in system without interface
We are building integration system. It main job is to gather data, make transformation and share those data. What good practices are in terms of creating user stories for such system ? We do not have user interface so the dev team has some problems with understanding "USER" story.
Aren't the INVEST criteria appropriate for Product Backlog Items in this case?
For me "invest criteria" will tell me WHY I want to do something. What kind of value this functionality/item will bring.
In my team we have a problem with proper describing such stories/tickets. They do not have proper user perspective and this leads to situation in which Dev Team has problems with understanding what a good story is and do it have everything that it should
User stories are a means to focus on
- Why are you doing something? What is the purpose?
- For whom are you doing it? Who will use it?
- What is it you're doing? How will it behave?
At the same time it's an anchor for capturing agreements of conversations, such as boundary conditions, legal requirements, or criteria of success. The INVEST principle is a tool that helps you to shape the user stories appropriately.
The user and the purpose help the team to inspect whether they are building the right thing.
In your situation, if it is hard to describe product backlog items (PBI) as user stories, maybe user stories are the wrong tool. We develop APIs for control test & measurement equipment. We use code snippets or examples plus some description as PBIs. They are not intended as specification but rather as an illustration of the usage context.
As long the development team and your stakeholders understand what a PBI encompasses and you can prioritize them and you can use them to get the development team deliver valuable increments, use whatever works for you. Don't get held back by some funny template text.
Maybe this could be a topic for a retrospective. What helps the development team to capture the essence of the increment? What do you need to manage it in a product backlog?
Thank you Gerd for your answer.
Yes, I know that user story is not a must. I also see that it does not fit here. Your example is very interesting. Can you tell me something about details level in terms of your PBIs ? How are you setting the limit from witch you will say "Ok guys. This is enough, let us not go further" ?
You're welcome, Dawid.
We do normal story point estimation. After all, it's a relative estimation like if it were a user story.
The independence of PBIs is often problematic since we have to cut them artificially small, which gives them kind of a natural order. If they are too big, you'll end up with the 80% done syndrome at the end of the sprint.