You should "should"!

I never thought I would grow attached to the word "should". Weighing in at around six letters, it seemed fairly unremarkable, however now I use many times every day. "It should show a login page when the user starts the app." "It should let the user set notifications to either on or off." "It should overload the constructor until you can't possibly understand what is going on." (Ok, maybe not that last one... more on that later.)

These "should" statements above are called user stories, and in agile development, these are what the developers are given to work on. You get a big ol' queue of user stories and start cranking from the top, marking stories complete as you go.

So, you might be wondering, what is so great about the whole "should" thing? Couldn't you phrase the stories like this:

"Show login page when app starts"
"Set notifications to on/off"

They are shorter and probably display better in your bug tracker, why bother with all this extra typing? I mean, what are you... a Java developer?!

In my experience, stories like the ones above are only one step away from the dreaded one-word-requirement:

"Login page"
"Notification settings"

Ok, two words, but still. It sounds like a caveman wrote the stories above... What should we work on next? "Login page!" Well what should that do? "Login page!" When should we show it? "LOGIN PAGE!" At that point, your customer clubs you over the head and finds another vendor wondering why you were too stupid to know exactly what was meant by "Login page".

How often have you seen requirements like this and scratched your head wondering what to do? I've had features that lasted for multiple months based on three words written in a meeting I didn't even attend.

Now, try to phrase the requirements above using the word "should". Can you make a caveman story with "should"? I dare you to try it. Even better, try to write the stories with both the words "should" and "user". "Login page" turns into "It should show a login page when the user starts the app" and suddenly you have an actionable story.

I'm not claiming that you can't write good stories without the word "should", I think that "Show login page when app starts" is completely fine. However, you can prevent the slippery slope toward the one-word-requirements by making "should" a requirement for your stories.

Another effect of writing your stories using "should" is that they become much manageable - exactly what agile says you should do. It's hard to write a giant requirement like "CMS" as a user story with "should". It becomes obvious pretty quickly that a story like "It should let the user manage content for each page and let them save content before publishing and should let them publish only if they have permission and should check whether content is already there and if so prompt and if not add it to the publish queue" is really multiple stories.

It also helps make your story scope easier to understand. "It should show the login page when a user starts the app" doesn't say anything about not showing the login page if the user has cached credentials. If that is also a requirement, it should be another story. By writing your stories this way, both the developers and clients can be much more clear about what expect when a story is delivered.

It's no coincidence that test frameworks like RSpec and Jasmine start each test with it("should ..."). It works well for the exact same reasons. Which of the following tests is easier to understand:

it("should update the user's credentials after login")
testLoginUpdateUserCredentials()

So, don't write caveman requirements, you should "should"! (That Geico guy is going to get me for this...)