As you probably know, the template I recommend for user stories includes a “so that” clause: “As a type of user, I want some goal so that some reason.”
Many of you have asked if this long form of a user story is really necessary—can’t we leave out the “so that?” The short answer is, of course you can. As a matter of fact, you don’t need to use the template at all if it isn’t helpful for you.
However, I do believe that understanding a user’s motivation is crucial to developing the right functionality for users. After all, users know what their problems are. They do not, however, necessarily know the solutions to those problems.
Let me give you a non-software example to illustrate. Years ago I was out of town working on a project. Because of some horrible pain on the left side of my stomach, I hadn’t been able to eat for three days. As soon as I finished the client engagement, instead of going to the airport to fly home, I went to the hospital.
I walked in grabbing my left side. By now the pain was intolerable. I told the nurse receptionist that I wanted to check into the hospital and have my appendix removed.
She told me she’d be happy to check me in, but she was pretty sure it wasn’t my appendix as the appendix is on the *opposite* side of my pain.
Essentially I’d shown up at the hospital with a story card saying, “I want my appendix out” or “remove appendix.” If a surgeon had delivered that feature request, I would have been no better for it and would have undergone unnecessary surgery.
I should have come into the hospital with a story of, “As a patient, I want my appendix removed so that the pain on my left side stops.” Saying why I wanted what I wanted helped the nurse and later the surgeon diagnose the real problem and deliver the appropriate solution.
Similarly, understanding a user’s reasons for wanting a particular feature can help a team deliver a more effective solution.
And that will help you succeed with agile,