(Professional Business Analyst Training

organisation)

Guidelines for preparing user stories in scrum

We use scrum when requirements are ever changing and fluctuate. In scrum requirement gathering is not a onetime task.It focuses on incremental unfolding requirements. In scrum requirements are represented as user stories.

High level capabilities and features are gathered as user stories in PRODUCT BACKLOG. It is a information bank about the activities to be done in entire project. In SPRINT BACKLOG, the scrum team identifies the user stories that will be worked on during the current sprint. The user stories further divided in to smaller tasks.

User stories should have 3 components.

i) Cards (Physical Medium).ii) Conversation(Discussion about story)iii) Confirmation(Test the validation Condition)

Traditional BA (Waterfall) Agile BA

Requirements are documented in Use Cases,Business Requirements, Functional requirements, UI Specifications, Business Rules.

Requirements are documented in Epics, User Stories and optionally Business (or Essential) Use cases.

   

Focuses on completeness of requirement and spends time in ensuring the requirement is unambiguous and has all the details.

Focuses on understanding the problem and being the domain expert so that s/he can answer questions from the development team swiftly and decisively.

Focuses on getting a ‘sign off’ on the requirements.

Focuses on ensuring the requirements meet the currentbusiness needs, even if it requires updating them.

Often there is a wall between the BA/Business and the Development team.

Agile BA (Often called as Product Owner) is part of the team.

Tends to dictate solutions.Has to remain in the problem domain, leaving the development team ‘space’ to explore different solutions.

Long turnaround. Quick turnaround.

Focus on what the requirements document said. In other words, output (Artifact) is a well written thorough requirements document.

Focus on the functionality of the developed software. In other words, output (Artifact) is the software that meets thebusiness needs.

   

In other way the user stories can be prepared using INVESTIndependent: User story should be stood on its own.Negotiable: User story Should capture essence not the details.Valuable: User story should provide value to the project.Estimable: Able to estimate how much time it takes.

Small : A user story should not take more than 8-16 hours. Testable: The user story should include validation criteria.

For dividing user stories in to small tasks SMART rule can be used.