I'm a newbie to the Agile/TDD world and trying to get my head around some of the basics. This is related to the way I should go about implementing user stories.
For e.g. lets assume I have below 2 user stories to start with for a hypothetical content management system:
Story 1:
As a Content Author
I need to be able to create News Articles
so that they can be used to attract users to the web site
Story 2:
As an Editor
I need to be able to view existing articles
so that I can review them to improve the quality
The way I would approach this is,
Area where my dilemma is about the As a part of the user story.
Specially in these examples they indirectly imply some Authentication,Authorization related requirments to me since the user stories mention about two user categories.
So my question is, whether I should have any tasks/tests that control Authentication/Authorization to the system to complete these user stories
Or
should I only focus on the I need to part of the user stories in trying to implement the functionality, and wait for any user stories that specifically mention about Authentication,Authorization related requirments?
All your inputs are highly appreciated.
Cheers.
You should definitely focus on the I need to part and consider the As a and so that as some kind of context.
There are many loopholes in your stories. The underlying Authorization/Identification part is one, another one I see is that the so that I attract more visitors to my website is something you can't really test, so you should think again and find another one (probably something simple and not very different like so that I can put them on my website to attract more visitors). I believe that with that format the so that part should contain some rough idea of how you'll test your story.
Really I use something much less formal for my stories : a title, a short description and some explanation of how to demo. I also add some priority value (important for the product owner) and a rough estimate of the work amount. The most usefull part is probably the How to demo as it will help writing tests (after breaking the story if necessary, but I also prefer, if possible, keeping stories shorts to avoid the need to break them). Also I try not to break stories to tasks but to smaller stories. Task is often too much about how you will do something and you should focus on what result you want.
In your case, there will most certainly be other stories and one will be about authentication someday, but that should not stop you to code pages now. Just go on step by step, keep your stories simple (you have tests, refactoring later is easy) and you'll quickly get the feeling of what works for you.
You should have a look at the excellent Book Scrum and XP from Trenches and see how they do it.