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?

  • None of those things sound like a user-story to me. Commented Mar 20, 2020 at 14:07

1 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.

  • Thanks for the clarification, glad to know these are all still applicable. I have also come across a 5th category, whereby there are existing fields in the system that the Product Owner doesn't want the users to use, but are part of the current workflow. Is it plausible to to write, "As a [User], I do not want the [field name] to have values entered?". Some of these are mandatory, others are not.
    – Philayyy
    Commented Mar 20, 2020 at 23:28
  • Just add the so what? at the end. What's important is not the field, it's the capability you are providing to the user. Commented Mar 21, 2020 at 13:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.