Comments on: Advantages of the “As a user, I want” user story template

By: Mike Cohn

Mike Cohn — Thu, 09 Feb 2012 15:23:06 +0000

For the project you describe and the items you list, I probably wouldn’t use this template. You could convert them to stories if you wanted (“As a developer, I want the database installed in the new environment so that I can program against it”) but I’d probably find little value to that over just “install database in new environment.” Part of the problem is that many of those items are things I’d view as tasks (one-person, one distinct bit of work) rather than user stories (multiple people, multiple steps). Plus, they are obviously technically focused.

I like the advice in the old Al Stewart song, “If it doesn’t come naturally, leave it.” Not everything needs to be forced into any template.

By: Hiren

Hiren — Thu, 09 Feb 2012 01:07:21 +0000

Hello Mike,

We are working on migration project to move many applications/systems from one agency to another. We are physically migrating hardware and software. There are many tasks involved. How can we turn these tasks into user stories with the format you suggested here, when there is no change in the business functionality at all. Few examples of tasks are listed below: (1) Identify Hardware components and software modules to be migrated. (2)Install database server in To-Be environment. (3) Install application software in To-Be environment. (4) Verify integration with connecting systems works in To-Be environment.

By: Mike Cohn

Mike Cohn — Thu, 12 Jan 2012 01:13:17 +0000

Hi Lianne-
I’m glad you find this blog enjoyable. Some teams will mix user stories and use cases. They’ll write high-level user stories (epics) and use a use case to document the story in more detail, for example. So while I see things like this occasionally, almost all of the companies I’ve seen do this have eventually moved away entirely from their use cases and to just user stories. Similarly in my classes, I hear much, much less discussion about use cases today than, for example, five years ago. Oddly, though, use cases have come up in a ScrumMaster class today and in some client work earlier in the week.

By: Lianne

Lianne — Wed, 11 Jan 2012 15:13:30 +0000

Hi Mike! I’ve enjoyed reading all the comments and especially your response. I am also a fan of the User Story Template because I think it helps to truly identify your goal. How do you feel about adding this ‘User Story’ as the scope of a Use Case? I am working on an Agile project where this format describes the User Goal best but we also need additional information that a Use Case format would supply.

Thanks!

By: Mike Cohn

Mike Cohn — Fri, 02 Dec 2011 10:56:48 +0000

Hi Hreinn–
I’m not a fan of that format. It doesn’t feel natural. Sure it fits all those tests into one “sentence” but it’s hardly a story. It might as well be an IEEE 830 spec. It seems to miss that the written part of a story is to lead to a conversation. That’s where those details come out. I advocate capturing them as tests or notes on the back of a story card.

By: Hreinn Eggertsson

Hreinn Eggertsson — Thu, 01 Dec 2011 23:42:47 +0000

Hi Mike,

I have a question or comment regarding the format of user stories, especially the acceptance criteria. I often feel the context is missing when the typical user story format is used.

I found this resource, http://dannorth.net/whats-in-a-story/ – and it uses the typical user story format, as discussed here, but adds to it a context, which could be described as acceptance critera in more details ..eg. as a user I want so that…GIVEN, WHEN, THEN..

example from the web site I mention (I only copied one scenario).

“START”
Story: Account Holder withdraws cash

As an Account Holder

I want to withdraw cash from an ATM

So that I can get money when the bank is closed

Scenario 1: Account has sufficient funds

Given the account balance is \$100

And the card is valid

And the machine contains enough money

When the Account Holder requests \$20

Then the ATM should dispense \$20

And the account balance should be \$80

And the card should be returned

“END”

What are your thougths on this? I assume this has been discussed somewhere in details?

thanks,
Hreinn

By: Mike Cohn

Mike Cohn — Mon, 21 Nov 2011 16:53:32 +0000

Hi Hass–
Thanks for sharing that. Our experiences have been completely different. Teams I’ve worked with have found that format forced–no one talks like that. So it may work fine among technologists but seems very contrived when working with real users or customers. But, the important thing is to have a variety of ways to try as no one solution will be right for all teams.

By: Hass Chapman

Hass Chapman — Mon, 21 Nov 2011 15:28:48 +0000

Actually I find the format: “in order to [get some value] I, as [a certain type of user], would like [some functionality].” much more useful and it focuses on the WHY part which is the part where most organisations I have coached have had problems and benefitted from improvements.

By: Mike Cohn

Mike Cohn — Mon, 07 Nov 2011 03:22:40 +0000

Thanks, Michael. I’m glad you like what I’ve done.

I think you’ve summarized it all perfectly. User stories become the items on your product backlog–and yes, the product backlog will have epics and regular stories on it. If you put up a story board that becomes your product backlog. Many teams will also put their sprint backlog on the wall—organized in rows with columns like “to do”, “in process” and “done.”

I think you’ve got all the terms down perfectly. Good luck!

By: Michael

Michael — Sat, 05 Nov 2011 18:35:00 +0000

Hello Mike,

Love your work!

I just want to make sure I am understanding this before I proceed at work. It has to do with implementing User Stories into Scrum.

I have developed a 3-column template, great idea, and am starting to gather User Stories/Epics. If I understand this right I can use these stories as actual items in my Product Backlog? The story board in essence becomes my Product Backlog?

From there we will eventually need to break the Epics into shorter stories but that just adds to the Product Backlog.

We then use the stories and transform them into workable tasks for the Sprint Backlog, right?

Sorry if I am using improper terminology, I am new to this.