IIndependent The user story should be self contained, in a way that there is no inherent dependency on another user story.
NNegotiable: User stories, up until they are part of an iteration, can always be changed and rewritten.
VValuable: A user story must deliver value to the end user.
EEstimable: You must always be able to estimate the size of a user story.
SSized appropriately or Small: User stories should not be so big as to become impossible to plan / task / prioritise with a certain level of certainty.
TTestable: The user story or its related description must provide the necessary information to make testing the development possible.
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.
你的故事里有很多漏洞。底层的授权/识别部分是一个，我看到的另一个是以便我吸引更多访问者访问我的网站是你无法真正测试的东西，所以你应该再考虑一下并找到另一个（可能是一些简单且没有太大不同的东西，例如这样我可以将它们放在我的网站上以吸引更多访问者）。我相信，采用这种格式，so that 部分应该包含一些关于如何测试故事的粗略想法。
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.
"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.
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.
发布评论
评论（6）
不必担心现阶段的影响。
用户故事应该是：
对另一个用户故事没有固有的依赖性。
故事，直到它们成为迭代的一部分，总是可以改变并且
重写。
估计用户故事的大小。
故事不应该太大而无法讲述
具有一定确定性的计划/任务/优先顺序。
必须提供必要的信息来测试开发
可能的。
[来源，维基百科]
如果尚未编写，您可以添加将授权故事添加到您的产品待办事项列表中，以便产品负责人确定优先级。授权故事可能会被其他团队（例如您的网络管理或类似团队）接管，因此请专注于提供您正在处理的故事所请求的功能。
Worry not about the implications at this stage.
A user story should be:
there is no inherent dependency on another user story.
stories, up until they are part of an iteration, can always be changed and
rewritten.
to estimate the size of a user story.
stories should not be so big as to become impossible to
plan / task / prioritise with a certain level of certainty.
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.
您绝对应该关注我需要部分，并将作为和所以视为某种上下文。
你的故事里有很多漏洞。底层的授权/识别部分是一个，我看到的另一个是以便我吸引更多访问者访问我的网站是你无法真正测试的东西，所以你应该再考虑一下并找到另一个（可能是一些简单且没有太大不同的东西，例如这样我可以将它们放在我的网站上以吸引更多访问者）。我相信，采用这种格式，so that 部分应该包含一些关于如何测试故事的粗略想法。
事实上，我在我的故事中使用了一些不太正式的东西：标题、简短描述和一些如何演示的解释。我还添加了一些优先级值（对产品所有者很重要）和工作量的粗略估计。最有用的部分可能是如何演示，因为它将有助于编写测试（如果需要的话，在打破故事之后，但如果可能的话，我也更喜欢保持故事简短，以避免需要打破它们） 。另外，我尽量不将故事分解为任务，而是分解为更小的故事。任务通常过多地涉及你将如何做某事，你应该关注你想要的结果。
就您而言，肯定还会有其他故事，其中一个故事有一天会与身份验证有关，但这不应阻止您现在编写页面代码。只要一步一步地进行，让你的故事保持简单（你有测试，以后的重构很容易），你很快就会感觉到什么对你有用。
您应该看看 Scrum 和 XP 的优秀书籍战壕并看看他们是如何做到的。
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
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:
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.
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.
至少我会生成故事：
如果没有人知道如何处理故事中的内容级别，我会与他们交谈/拿起电话/发起即时通讯并与他们核实。您可以在较低级别对您不想实现的功能进行 TDD，但是端到端故事的任何测试自动化都应该经历用户所做的事情。
这些故事的问题在于，您可能会考虑底层任务，但从用户的角度来看，您最终可能会发现客户想要更多具有 openid/登录功能且具有现有帐户感觉的博客。 它毕竟是敏捷的，它是滚动/全面沟通的方式，而不是在大型分析+设计阶段全部定义的。
当用户名/密码/哈希值/等可能与项目无关时，没有必要花一秒钟的时间来思考。
无论你做什么，都要保持简单。
PS。这都是故事不可或缺的一部分，它只是恰好依赖于其他故事的到位。
At the very least I'd spawn stories for:
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.