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.
Technically no, according to 1st Agile manifesto principle ["Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."], because technical requirements explain only the details of implementation, deployment, maintenance and not the business value they bring to the product.
According to what you're talking about that only technical requirements are needed, it's either a self-explanatory particular task, or these requirements are not pure technical and still contain the explanation of a purpose they serve i.e. business value. Because business value is about the profit the User get from using this Product and this Feature instead of anything else (e.g. User can save/earn money, adore the UI or get a feature set covering his paramount needs, when no other apps can do, etc.).
Interesting question. It’s a pity that I didn’t see it before - it makes me remember that business value is both functional and technical combined, meanwhile the division of functional requirements vs technical requirements was invented only for convenience and simplicity.