Should User Stories be written for non-build requirements?

Question

I am working on a project which is introducing a new Business Product, that is leveraging existing systems

From a requirements perspective, they fall into all these types:

1. A system change is required --> i.e. new field, field modification
2. Plain use of the existing field --> i.e. field will be used as it currently does for other products
3. Use of the existing field, but with manual processes specific to that field --> i.e.if the value being entered is greater than $500, then call the manager over from their desk to say "go for it!" before proceeding
4. Complete manually processes outside of the system context --> i.e. ID and Verify the customer on the phone

Would all these scenarios be eligible for a User Story? How would it be best to ID and segregate build vs non-build stories when tasks are later assigned?

Answer 1

A User Story indicates the impact to users with the business reason for the work to be done. There are tasks that need to get done that don't directly affect users, for example setting up infrastructure or paying down technical debt. However, the examples you provided all look like they have a user impacted reason to exist.

As a [type of user] I want to [action or impact] so that [business reason]

For example, say you needed to add a new field to track when a request was completed. An example user story would be:

As a supervisor I want to know when a request is completed so that I can monitor the team's current workload.

Of course the reason to have a user story is to start the process of changing your product, not someone else's.

All of your changes to the product should originate from wanting to enable some feature for your users. However, when you break down the work that needs to happen for a user story, you often just have tasks. When the associated tasks are complete, the user story is complete. For that reason, you need to be able to trace those tasks to the parent user story that is being required.

At that point, options include:

• Create sub-tasks for the parent user story
• Create separate tasks, but link them to the parent user story

Keep in mind not all requirements for your software come from end users. You can have developers requiring DevOps pipelines to manage and optimize their work. Some teams create the user story which starts with "As a developer I need...". Other teams just track them as tasks. And that's OK.