Use Case OR User Story?
Hello
suppose that we have a system analyst that collect requirements from users then sends them to development team in a document;
the developers needs ONLY the areas of business that were selected for automation, and I think that Use Case is more than enough to tell the developer IN DETAILS how the automation will be because the components of the Use Case are very rich in information
BUT some people think that use case are deticated for TRADITIONAL requirements!! and in SCRUM the new technique is USER STORY
I think SCRUM gives the development team the free to choose any technique that help them to clarify the requirements whether its use case OR user story
any different IDEA?
You are correct. Scrum has "Product Backlog Item" and does not define what that is.
So you can choose whatever format you want to use: Use Case, User Story or anything else.
I'd suggest that neither use cases, user stories, nor any other form of backlog item are used to clarify requirements. Rather, it's the act of releasing finished work -- and being able to inspect and adapt through empirical feedback -- which does so.
If it's actually possible to tell the developers "in detail" about what is needed, then it may be worth questioning whether Scrum is a good fit for the challenge.
Scrum does not mandate the use of user stories, or any other particular way of representing work on the Product Backlog. So you're right that the development team is free to choose any technique that works for them. I'd suggest that it's not entirely up to the development team, though. There may be considerations around what other stakeholders are familiar or comfortable with to make communication easier. The decision on how to represent the Product Backlog should consider everyone who needs to get information from the backlog and make an informed decision.
It's not necessarily a binary decision between using use cases and user stories. It could be worth investigating Ivar Jacobson's Use Case 2.0, which combines traditional use cases with user stories.
Many thanks for replies and care
Ian Mitchell, excuse me, I'm not as expert as you; but what I understood in SCRUM(or Agile in general) is that the BA(or SA) is allowed to document the requirements with any technique BUT he should be carefull to produce short documnets that has ONLY THE ENOUGH level of details with NO EXTAR details
I need your commentary
Individuals and interactions over processes and tools
It does not matter. The technique does not matter at all. They (PO and the Developers) have to talk, they have to interact. In Agile, it is POls responsibility to explain until she/he is sure the Developers fully understand. In Agile, it is responsibility of the Developers to ask the PO until they are sure they understood her/him well. It is never too late to ask a good question, it is never bad time to clarify a requirement. More: it is not a problem if the answer given by PO has changed since yesterday, even in the middle of implementation. It is better to re-work half of already implemented PBI than deliver something useless.
There is no boundary between the PO and the Developers. They are one Scrum Team. They share one goal. So there are no "agreed formal criteria for handover from PO to the Developers" of any kind. There must be nothing like: "I do it until that point, as we agreed, I hand it over to you and then I don't care, cause it is your responsibility now". That is not Agile.
Having that in mind, the PO and Developers are free to choose tools and techniques they prefer. Scrum Guide is clear here: they are free to use whatever works best for all of them.
They are also self-managing, meaning they internally decide who does what, when, and how.
Many Thanks for you Henryk Kolek
Yes; I like too much to Specify which one of Agile's 4 values ( or its 12 principles) is pertaining to that Issue when somebody explains any issue
many thanks again