A user story can be defined in a sentence like:

As a <type of user> I want <some goal> so that <some reason>

Just Google for 'user story formula' and first links all propose this formula.

My question is, what is the purpose of so that clause? Is it there for managers? Is it there so that project managers and stakeholders can understand the priority of the item better? Why is it there?

Note: I've worked with as a <type of user> I want <some goal> formula, and it works just well. I haven't noticed any problem in my work by implementing this format which is more brief.


3 Answers 3


The purpose is to avoid unnecessary work by forcing the user/customer to supply a solid, tangible business benefit as a reason for the existence of this feature.

It is not unheard of that features get added just because someone thought they sounded cool, or because other software has it, so ours must have it, too. More often than not, those are at least completely unneccessary, if not actively harmful.

However, it is usually easy to spot those features, because the people proposing them generally will have trouble supplying a convincing business reason for them.

There is a technique called Popping The Why Stack, where you take the "so that" part, and ask "Why?", then you take that answer, and ask "Why?" again, recursively. If, after (let's say) three to five "Why"s, you have not arrived at either "because it'll make us money" or "because it'll save us money" (preferably with a precise description of exactly how that is going to happen), then the feature isn't worth implementing.

Some people believe this to be so important that they actually put it first in the story template:

In order to [...]

As a [...]

I want to [...]

There's a great example from a talk by some Thoughtworks people: one of their clients wanted the printed reports formatted in a very peculiar way. When the consultant asked "Why", they said that that way they were easier to type back in. So, instead of implementing the report formatting feature, they just transferred the reports over the network. Without the "so that" clause, they would still be printing theose papers out in one department, mailing them over to the other department and typing them back in.

  • What you described is called the Five Whys (en.wikipedia.org/wiki/5_Whys) and it's generally useful in (software) engineering fields, ranging from requirements engineering to quality control to process improvement. It's probably a good skill to develop.
    – Thomas Owens
    Sep 5, 2011 at 15:49
  • Love the ThoughtWorks story. I found that the "So that" is very useful in providing context behind the story, and helping developers provide a better solution. Analysts/clients often narrow down too fast on a solution; providing developers with the context enables them to think and design a technical solution the analysts may not have considered, or might not think possible.
    – Mathias
    Sep 5, 2011 at 20:40

The "so that" provides a reason for the goal.

For example, the goal might be to display last month's sales figures. You could work with that, but one reason you need to know why you want to display them so that you can get at the deeper requirements. What do they want to do with the sales figures or prospects? Knowing this information will give you more insight into the application and more chance of designing a user interface that enables the customer to do what they want.

Another use for the reason is to prioritise stories. If you have two stories:

I want to display last month's sales figures.
I want to display a list of prospects.

but only have the resources to do one - which one do you do? Without the reason you'd just be guessing and you might not deliver the right one in time. Though this is less important as the customer should be telling you which to do first, but occasionally that isn't the case.

  • I don't think it's about prioritizing stories, but rather the deeper requirements. The stories should be prioritized by the customer. However, the "so that" can be used to elicit additional requirements (functional, nonfunctional, and quality attributes) that will add value for the user. The concept of maximizing value added is one of the strengths of many of the agile methods, I think.
    – Thomas Owens
    Sep 5, 2011 at 13:59
  • @Thomas - good point. I'll swap the reasons - I think the prioritizing is there, but not as important.
    – ChrisF
    Sep 5, 2011 at 14:01

In addition to what have been said, providing a reason for the requirements allows you to judge the validity of the requirement. The user may want things for the wrong reason. Having the "so that" clarifies the reason hence allows the analyst to validate that the request is best satisfied in this way.


A-I want to be able to select employees from a list of all company employees

B-I want to be able to select employees from a list of all company employees so that I can delete the ones that have left the company 5 years ago.

(B) does not make sense even in a medium organization, but you can validate the user requirement and propose another way for the customer to fulfill the requirement.

  • +1 - it helps to get to the root of the problem; otherwise you're just given a potential solution.
    – JeffO
    Sep 5, 2011 at 21:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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