“As an Agile developer, I want the ‘so that’ component of all User Stories to be completed, so that I can understand the business value of the requirement, and make correct decisions –  or have appropriate discussions – based on that understanding.”

Far too often in the Agile world, customers are encouraged to provide requirements based on ‘What’ they want, with minimal attention paid to the question of ‘Why’.  The primary motivator being that without the ‘What’, there is nothing to deliver!  Unfortunately, without the ‘Why’, what ends up being delivered may not best solve the customer’s original problem.

Wait a second… who said anything about a problem??

At the lowest level, any piece of functionality a customer could ever want is essentially the answer to a specific problem.  For instance “As an app user, I want all buttons to be yellow” may be the answer to any one of the following problems:

  • The current buttons colour scheme causes difficulties for colour blind users.
  • Users are complaining that the app is too bland and dreary.
  • There is an overall push to utilize corporate colour schemes for consistency.
  • The button text is difficult to read, as the font colour is too similar to the current background colour.

If the development team has no knowledge of the underlying problem this requirement is trying to address, two things might happen:

  • They could fail to solve the problem!
    • For instance if the problem was corporate colour consistency, choosing the wrong yellow wouldn’t solve the problem.
    • They could deliver a solution that is not the best way to solve the problem.
      • For instance if the problem was a bland app, yellow buttons may improve things, but likely not enough in many user’s eyes.

Let’s consider the first examples above and what the outcome could be with the presence of a simple “So that” clause in the User Story…

“As an app user, I want all buttons to be yellow, so that they match the corporate logo.”

This tells the development team something very specific and greatly increases the chance the deliverable will match the customer’s needs.  It can’t be any random shade of yellow, it has to specifically match the corporate colour scheme.

Without a doubt, the presence of the business value helped to clarify the requirement.  Unfortunately, the customer’s deeper problem was only partially remedied.  It turns out that using the corporate colours was how the customer had hoped to improve overall consistency within the app.   Essentially the customer was providing a potential solution to a problem without explaining what the problem was!   Let’s rewrite the User Story with the problem explicitly called out in the “so that” clause…

“As an app user, I want all buttons to be yellow, so that they match the corporate logo and create a more consistent user experience”

By stating the problem it creates opportunities to discuss other potential solutions.  This may lead to other stories that further help solve the problem, or it may even result in this story being replaced with something that better solves the problem.  At the very least it should lead to some discussions around “What is causing the user experience to be inconsistent?”.

Perhaps the underlying cause of the inconsistent experience has very little to do with the colour scheme, but rather that buttons themselves!  For example, if most of the app relies on particular gestures for navigation, but a few screens change that up with button clicks, the user experience is clearly inconsistent.  Changing the colour scheme may improve the visual consistency, but the user experience problem won’t be improved at all!

With knowledge of the problem in mind, the development team can open discussions with the customer on other ways to solve that problem.  It might even lead to dropping the initial story and replacing it with the following:

“As an app user, I want all navigation buttons replaced with existing navigation gestures, so that navigation in the app is the same on every screen”

In this case, the problem being addressed is quite clearly that app navigation is inconsistent.  If there are other user experience issues, those can be handled in other stories.  Further, this story could perhaps be reversed so that instead all navigation is done via button clicks as that also solves the problem; having the problem identified allows for this option to at least be considered.

As important as the question of ‘What’ is, it is equally important that Agile teams spend time focusing on the ‘Why’ in order to maximize the value of all deliverables.