Decoupling User Stories in Agile Development

Question

Based on what I've read, user stories are often cast in a "who", "what", and "why" format, i.e. "[Who] wants the system to do [What], so that [Why]". The "who" and "what" seem easy to grasp. For the example of an ATM:

As a customer
I want to be able to deposit money
[Why]

The "why" line seems like it could have a significant impact on the scope of the software. For example, all of the following seem like reasonable justifications for the feature; however, the first implies security, insurance, data redundancy, etc...; the second and third imply the existence entirely separate systems; and all three imply data persistence.

So that it will be protected by the bank
So that I can manage my finances online
So that make payments with my debit card

To put it briefly, within the context of agile software development, how are complex/coupled functional requirements handled so that they can be sanely developed?

For example, would the development team derive sets of use cases from such high-level user stories? Or would they re-write the user stories so that they had a limited scope?

Answer 1

Hmm I don't think any of those whys are useful for a user story.

The why in this format is suppose to give insight to the developer so that they don't follow the letter of the spec rather than the spirit of it.

Additional your User type "Customer" is possibly unhelpful. I would go with..

As a: _BankAccountOwner_
I want to: pay money into my bank account, 
  from another banks debit card, 
  by filling in a form online
So that: I can later withdraw it.

Now the developer knows that its the BankAccountOwner type of customer that's doing this, so they can fit it in with their other stories.

They know the general specification of the thing we are trying to achieve, "deposit money via webpage"

And they know the expectation of the user, "They will be able to withdraw the money later" and so include any technical details that will be needed, (bit hard in this limited example but ..)

• It should go to the users bank account not someone else's
• It shouldn't automatically pay off loans or anything
• Don't accept money if the bank is going bust
• Warn the customer if for whatever reason they wont be able to withdraw for X days

The Why enables a briefer specification and can prompt questions from the developer where they might be required. "Other Story Y says we should always pay off the loans first?" etc

On your second point "how do you do stuff from such high level stories?" Well your example is pretty high level. You'll notice I had to add some details to it as well as the other changes. But generally you just do them and add more. eg

as a _BankAccountOwner_
I want to : pay money into my account
  with a credit card... etc

as a _BankAccountOwner_
when paying money into my account
I want to : be told my current balance

In a case like banking you probably have a million and one requirements in advance, because they are so well known. But normally you either have an existing system in place which you are adding to, or you are starting from really basic "Sprint Zero" stuff

As a: _Bank_
I want to : have a website
so that : I can provide services to _BankAccountOwner_

As a: _Bank_
I want to : have an ssl cert for my website
so that : I comply with laws X, Y and Z

etc

Answer 2

The one-sentence wording of a user story is not meant to be the carrier of the functional requirements. It's only a summary. The full details behind this user story are clarified through a two-way conversation between the product owner and the team shortly before the sprint (at the sprint planning meeting, or shortly before at a back log grooming meeting). There is no need for a formal record of those requirements, but if desired, the product owner can record the most important conclusions of this conversation in the form of acceptance criteria.

If a user story is too vague in the beginning, then the product owner should simply provide more information and answer questions from the team. Only if the team concludes that it's too big for one sprint, then the product owner needs to split the story: Replace it by multiple user stories (often with help from the team).

So to get back to your question:

How are complex functional requirements handled?

1. They are broken down in user stories small enough to swallow in one sprint.
2. These user stories are clarified through conversation, shortly before the sprint

Answer 3

The "why" line seems like it could have a significant impact on the scope of the software.

No, the why doesn't affect the scope of the software at all. It is a justification for the story, but not a requirement that the story must fulfill. It exists to help the developer understand the importance of the story, and possibly how it fits into the big picture.

Answer 4

There are a few other answers, but I think this is missed in the others:

The why here isn't why I want to deposit money in a bank account (as opposed to my mattress). The why is why I want to do it through the ATM. The answer to this can influence the functionality.

For example, if the why is "so I can deposit and use my money even after the bank is closed" then simply taking the money or check without applying a deposit transaction to my bank account doesn't fulfill the user need.