Home/ Questions/Q 87341
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T22:23:16+00:00

I’m writing a small app for my friend’s business, and thought I’d take the

  • 0

I’m writing a small app for my friend’s business, and thought I’d take the opportunity to brush up on some Agile Project Management training I did at the start of the year.

I (and I think, my current organisation!) have always struggled with gathering requirements in the form of User Stories, which take the form:

As a [User Type] I want [feature] so that [some benefit]

I’m always tempted to miss out the beginning and end, and just leave the feature – but this then just becomes requirements gathering the old way!

But I don’t want to just make it fit, so that I can say ‘I’m doing Agile’…. for example, if I know that the user is to be presented with a list of items, then the reason is self-evident, is it not?

e.g.

As a [Store Manager] I want [to see a list of Stock Items] so that … ?

Is it normal practice to leave out the [so that] clause?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. We used to miss it out as well. And by leaving it out we missed a lot. To understand the feature properly and not just do the thing right but DO THE RIGHT THING it is key to know WHY the feature, and for that the next key is WHO (the role) In DDD terms, stakeholder. Stakeholders can be different, everyone who cares. From programmers and db admins to all the types of users.

    So, first understand, who is the stakeholder, then you know 50% of WHY he cares, then the benefit, and then it is already almost obviously WHAT to implement.

    Try to not just write ‘as a user’. Specify. ‘as store manager’, or even ‘as the lead of the shift responsible for closing the day’, i need….so that….

    Maybe you can implement something different which will give the same stakeholder even better benefit!!!

    • 0