Resourcer User Stories

I’ve been hard at work writing Resourcer User Stories. I’ve come up with 85+ user stories, though a few are quite repetitive. I’ve been following the Head First Software Development book which comes highly recommended from me! It’s a great book, quite entertaining, and full of quizes, pictures, and thought-provoking elements that make you remember things, rather than just being another reference book on the shelf.

My favourite tip: Easy User Stories. A user story is:

One feature of the software that the user can understand. It should be less than three sentences in length, contain a title and description, and priority. It should take less than seven development days to implement.

That’s it. So simple. You can dress it up into a use case with alternate flows and exceptions, but really if you’re working in a small team like I am, user stories are more than enough. Do note some of the criteria of a user story:

1. It is one feature. If your user story has an “and” or “or” in it, that’s more than one feature.
2. The user can understand it. You can’t mention AJAX, since what does that mean to the end user. You could say it must look good and act like a desktop application not a webpage. You could say it needs a place to save data, or it must import users from another application. But you can’t say it it must have a MySQL backend or import users to an XML web service, unless your users understand this.
3. It should be less than three sentences in length. How long does it take to describe one feature? If it’s going on and on, it’s probably more than one feature… Not too much detail here, it’s not a design document.
4. It should take less than seven days to implement. Sounds difficult. If it’s bigger, cut it down. Cut it down. Cut it down. A user logging in could actually mean a user logging in by SAML or LDAP. Different features.

So why the focus on small features? Simple, easy to complete, easy to test, easy to demo, easy to get paid.