Implementing User Stories the Agile Way [closed]

Question

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,

• I would grab one of these user stories
• break the I need to part of the user story into smaller pieces of tasks
• Grab these tasks one by one and come up with Tests to cover the specific task
• Implement tasks the TDD way

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.

Answer 1

Worry not about the implications at this stage.

A user story should be:

• I Independent The user story should be self contained, in a way that there is no inherent dependency on another user story.
• N Negotiable: User stories, up until they are part of an iteration, can always be changed and rewritten.
• V Valuable: A user story must deliver value to the end user.
• E Estimable: You must always be able to estimate the size of a user story.
• S Sized appropriately or Small: User stories should not be so big as to become impossible to plan / task / prioritise with a certain level of certainty.
• T Testable: The user story or its related description must provide the necessary information to make testing the development possible.

[Source, Wikipedia]

If they haven't been wriiten yet, you can add the authorisation stories to your product backlog for the product owner to prioritise. The authorisation stories may be picked up by some other team, such as your network administration or similar, so concentrate on delivering the functionaility requested by the story that you are working on.

Answer 2

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.