It is more convenient for me to describe requirements in technical terms. So is it possible not to use the users stories in Scrum? Will it be Agile still?
Of course you may! Scrum doesn't prescribe what concrete representation of requirements you should use. There is no such term as "user story" in Scrum Guide at all. Scrum Guide operate "Product Backlog Item" instead.
Scrum Guide imposes three constraints to well defined (or "refined" in Scrum terminology) PBI:
- It should be clear to all Scrum Team members.
- It should be well detailed.
- It should be possible to implement this PBI within one Sprint.
So, theoretically PBI can be any kind of requirement representation.
Main reason, why User Story is used: it is more customer oriented.
But if you are Product Owner and you have no communication problem with Stakeholders, you may feel free to operate with such kind of requirements representation as you want.
Finally, quote from Scrum Primer:
Product Backlog items are articulated in any way that is clear and sustainable. Contrary to popular misunderstanding, the Product Backlog does not contain “user stories”; it simply contains items. Those items can be expressed as user stories, use cases, or any other requirements approach that the group finds useful. But whatever the approach, most items should focus on delivering value to customers.
So, if it is okay for your stakeholders, there is no problem even if you will operate "SRS style" requirements (like "system shall..." phrases).
Having a user story is kinda central to forming a scrum team. Technically I would say you are not "doing scrum." It may still be Agile if it works for your team and your customer however...
The decision on whether or not to use user stories should not be based on convenience to you, it should be based on what the team needs to succeed and what needs to be done so that the customer gets a quality product increment at the end of the iteration.
If the team can think out of the box enough (and understand the business value of the work item you document) to solution and build something for a customer in an iteration without a formal user story...then go for it. If you are writing implementation details for your team and they feel like "code monkeys" then you are defeating the purpose of using Scrum and empowering team to deliver incremental value to a customer.