Implementing User Stories the Agile Way [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this 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 hyp开发者_开发技巧othetical 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.

---

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.

---

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.

---

The phrase

"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"

is not the story. It is a summary of the story that fits on a card or in a spreadsheet column and represents the story so you can remember which one you're talking about. The whole story is composed of three parts - Card, Conversation and Confirmation - and the part you need here is the conversation.

Talk to the user or the user representative in your team to find out what it really means.

---

As a part does not imply Authentication or Authorization. In the same way you can write a user story as:

• As a new visitor ...
• As a returning visitor ...

Does it mean that visitor has to be authenticated? What authorization vistor has? User stories should not include "hidden requirement". If you need authentication and authorization simply create user story for that.

As a part specifies type of user roles in your application. Each role has some special needs and requirements and uses application from different reason. You should try to collect roles before you start to write user stories.

A user story does not contain only description. It should contain additional information which are added in different phases of the process.

• Description in defined format. You don't have to use As a ... I need ... so that ... if you think it doesn't fit your needs but you should use same format for all stories.
• DoD - definition of done also known as acceptance criteria. This should be collected with description. User story without DoD is useless. DoD says developer additional information about user story. User story is completed only if it fulfills DoD. You can also create automated acceptance tests based on these criterias.
• Priority set by customer - this will help you sort user stories by importance
• Estimate - made by team. Estimate is not exact it should be based on comparison among user stories. Usual units of estimate is abstract story point or t-shirt size.

Also be aware that not every user story is decomposed to tasks directly. You can have big high level user story which will be first decomposed to smaller user stories. We call such user story Epic.

---

You could initially make the assumption that the user is authorized to make changes, then tackle the authorization as separate stories later on (when they become the most important items in your backlog).

This has the benefit of keeping the scope of your stories small so they are easier to work with, and also gets the initial stories in a potentially deployable state earlier on.

---

At the very least I'd spawn stories for:

1. authenticate user
2. signup Author / Editor ... or signup User, assign permissions

If no one knows how that'd be handle those at the story level, I'd talk to/grab the phone/initiate im and check with them. You can TDD your way at the lower level for the feature that you wan't to implement, but any test automation on end-to-end story should go through what the user does.

The thing with those stories is that you might be thinking in the underlying tasks, but from the user point of view you might end up finding that the client wanted more of a blog with openid/login with existing account feeling. Its agile after all, its the way it rolls / full communication instead of an all defined in a large analysis + design phase.

No point in dedicating a sec of thought to usernames/password/hashes/etc when that might not even relate to the project.

Whatever you do, keep it simple.

ps. its all an integral part of the story, it just happens to depend on other stories being in place.