5

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?

2
  • 1
    i think the 'scrumness' of a user stories is that it pushes you towards defining work items in terms of actual finished functionality that the business understands – Ewan Jun 20 '15 at 22:03
  • Will it be Scrum and will it be Agile are different questions. Scrum doesn't imply agility. Neither it requires using User Stories. – Stanislav Bashkyrtsev Dec 23 '20 at 9:30
9

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).

2
  • What does SRS mean? – LeDarge Jun 4 '15 at 9:46
  • @LeDarge Software Requirements Specification. Usually, requirements are described in this document much more formal and with more technical terms, than in User Stories. That why I wrote about "SRS Style". – Sergey Kudryavtsev Jun 4 '15 at 10:42
0

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.

1
  • User Stories is just a text format, it's not central to anything. – Stanislav Bashkyrtsev Dec 23 '20 at 9:33
0

Technically no, according to 1st Agile manifesto principle ["Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."][1], 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.

3
  • How you manage tasks and whether your create valuable software are 2 different things. Agile manifesto doesn't put any constraints on how you manage tasks. – Stanislav Bashkyrtsev Dec 23 '20 at 9:32
  • The Question contains nothing about 'task management', only the statement "to describe requirements in technical terms.". I've answered from the point of the profit which the user story brings aside pure technical requirements, which specify it and take place on the level of technical tasks after the decomposition of the high-level requirements to busines and technical ones. – elisarea Dec 23 '20 at 14:04
  • User Story is a format of describing tasks, so one implies the other. In the end it doesn't matter how you communicated your thoughts (whether you discussed business value or not) - what matters is that you deliver the value. And the quote that you copied says (though it's from Agile manifesto while the question is probably about Scrum, but who knows..) "continuous delivery of valuable software" – Stanislav Bashkyrtsev Dec 23 '20 at 14:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.