user stories and tasks outside software development projets
We talk about user stories and tasks in software development projects. What do we call these user stories and tasks outside of software development projects ?.
thank you
Scrum refers to work in the Backlog as Product Backlog Items.
I'm not sure how these work items are being used outside of software development but I'm typically an advocate for:
a) call it what it is
b) call it what you want just make sure anyone involved in the process has a clear understanding of what is meant by the term.
What do we call these user stories
Placeholders for conversations about potential requirements
and tasks
The plan of work emerging from these conversations
Merci, mais ce n'est pas encore claire. Y a t'il un cas d'exemple?. Pourquoi on ne trouve pas des exemples au même titre que le développement logiciel sur les sites spécialisés?
Why can't you continue to use User Stories and Tasks outside of software development. An User Story is a way to state a problem from a user persepective.
As a < type of user >, I want < some goal > so that < some reason >.
I don't see why that can't also work for any other business. For example
- As an <in store retail customer>, I want <to easily find the section of the store containing small appliances> so that <I can quickly buy a blender>
- As a <patient at a family clinicn<>, I want <to be able to find the laboratory> so that <I can complete the lab work that was just ordered by my physician>.
Both of those user stories could be satisifed without any software development and in fact would probably be solved with signage that was visible and easy to understand. As for the tasks associated,
- determine location for signate
- design signs
- create signs
- hangs signs
But also remember that User Stories are not required by Scrum. They are a practice from Extreme Programming that many have found useful. Scrum just prescribes
Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done".
That can be done in any form you want as long as everyone involved can read it, understand what needs to be done and why.