What is a User Story?
User Story... What's that? Acceptance criteria... Why do we need that? Sub-task... Well, we probably know what a sub-task is, but let's examine the topic of User Story as a whole a bit deeper, and see what is important for a good User Story, and what isn't
In software development a user story is an informal, non technical description of one or many features of a software system.
They are most of the time written from the perspective of an end-user, with the desire to accomplish specific tasks. Often recorded on cards, Post-It notes or logged into a project management software (hint: Auroria is such a project managment software ;) ).
Depending on the type and circumstances of the project, user stories may be written by various stakeholders like clients, users themselves, managers or members of the development team.
User Stories are written by or for, sometimes even by and for users to influence the functionality of the system being developed by the development team.
In some projects, the product owner is primarily responsible for formulating the user stories and organizing them in the product backlog, in other teams anyone can write a user story.
User stories are a central part of many agile development methodologies, they describe what may be built for the product by the development team.
The prioritization of these user stories is most of the time done by the customer (the product owner in SCRUM) to rank them according to their importance.
These user stories are then split up into sub-tasks which are estimated by the development team, describing the different steps needed for the user story to be implemented on a technical basis.
Acceptance criterias are kind of "notes" about what must be accomplished by the implementation of the user story for the product owner to accept it as "done".
They define the boundaries of a user story and are used to confirm when a user story is working as intended.