User story has a particular meaning in software development:
but there is no reason to restrict yourself to those limited definitions. A user story is a way to describe and capture a workflow, a process, that you as a scientist might do daily, or weekly or more rarely.
This is an example of a user story in the context of climate modelling:
Writing down your user story can help you understand it better. Sharing it on a forum like this then allows colleagues to recognise when this corresponds to their user story. Then you have a shared basis for collaboration, where you can help each other to improve your workflows.
User stories describe a workflow or process that can be used as a basis for new users to copy and adapt.
User stories are also helpful for ACCESS-NRI as a basis for targeting improvements in documentation, tools, processes, or model code to improve the productivity of anyone who has a similar user story or workflow. This helps you and your colleagues.
User stories are essential because you are the subject matter experts with the experience in your field. This is particularly important as many staff at ACCESS-NRI are not subject matter experts, and so we need your help to make better products for you.
A user story can be constantly improved, to reflect improvements, or to add features or processes that are new or that might have been omitted originally. To facilitate this it is best to make a user story a wiki post so that it can be constantly updated.
ACCESS-NRI would like to use user-stories as qualitative measures of impact and improvement for the community. In many cases what we might do can’t be well measured in metrics, but the community will “just know” it is a lot easier than it used to be. User stories are a way to capture this improvement, by documenting the improvement in the workflow for a particular user story. This helps demonstrate the value ACCESS-NRI brings to you, the community, to the bodies that fund us.