Technical stories
We always think in backlog with user stories.
But What happen when the issue is from other system and not from a user?
For exemplo: I have one "enabled squad" that develop technical components for many areas in my company.
Is everything OK if my storie use just a description and not a convencional structure,?
What do you think about?
Convercional structure means:
As an user
I would like to
...
In order to:
...
Everything would be OK. Scrum does not prescribe how to describe a Product Backlog item. The User Story ubiquitous structure you describe is a complimentary practice, but by no means required.
So describe it however your Development Team will understand it. And always remember that the conversation is even more important.
@Chris is completely correct. As long as you communicating the needed information in a form that everyone understands and there is some way to know if the problem has been successfully addressed, anything is OK.
If your development wants to have a "story" format, there are numerous ones that can be used. I have had some success with these two.
- In order to <deliver some benefit> <these people> will need <this function>.
- In order to <deliver some benefit> <this system> must <deliver this function>.
For exemplo: I have one "enabled squad" that develop technical components for many areas in my company.
Is everything OK if my storie use just a description and not a convencional structure,?
A Product Backlog item ought to have a description, a value, an order, and an estimate. How would you describe the value being provided by these "technical" items, so that valuable feature-complete increments can be planned and delivered?
You can create these technical stories as enablers stories.
Multiple user stories can be dependent on this story.
- In order to <deliver some benefit> <this system> must <deliver this function>.
@Daniel: I like that one. Thanks.