Comments on: Advantages of the “As a user, I want” user story template http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template Succeeding With Agile® Wed, 17 Mar 2010 11:09:10 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Experience vs Memory in Projects and Business - ekeepo http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template/comment-page-2#comment-67132 Experience vs Memory in Projects and Business - ekeepo Tue, 02 Mar 2010 00:38:54 +0000 http://blog.mountaingoatsoftware.com/?p=24#comment-67132 [...] month and what needs to be done that day to succeed per the defined goal.  As Mike Cohn writes (http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template) a user story in Agile Software Development is often in the form of “As a <type of user>, I [...] [...] month and what needs to be done that day to succeed per the defined goal.  As Mike Cohn writes (http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template) a user story in Agile Software Development is often in the form of “As a <type of user>, I [...]

]]> By: OCTO talks ! » Cucumber pour l’AMOA http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template/comment-page-2#comment-61111 OCTO talks ! » Cucumber pour l’AMOA Fri, 11 Dec 2009 16:07:20 +0000 http://blog.mountaingoatsoftware.com/?p=24#comment-61111 [...] Langage Naturel… « Alors déjà Vincent, nous, franchement, quand on relit nos tests, on reconnait plus certaines choses… C’est quoi tous ces mots clés qui apparaissent dans nos tests après le passage des développeurs? Ca devient illisible! » Sandie AMOA. Et si, messieurs dames de l’AMOA, vous utilisiez le langage naturel? Si, chaque action de votre scénario de recette était une jolie phrase en français, sans tableau? Et si, vous aviez juste à utiliser ce formalisme simple (décrit par ailleurs par « M. SCRUM » ici): [...] [...] Langage Naturel… « Alors déjà Vincent, nous, franchement, quand on relit nos tests, on reconnait plus certaines choses… C’est quoi tous ces mots clés qui apparaissent dans nos tests après le passage des développeurs? Ca devient illisible! » Sandie AMOA. Et si, messieurs dames de l’AMOA, vous utilisiez le langage naturel? Si, chaque action de votre scénario de recette était une jolie phrase en français, sans tableau? Et si, vous aviez juste à utiliser ce formalisme simple (décrit par ailleurs par « M. SCRUM » ici): [...]

]]> By: The People’s Scrum « Agile Anarchy http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template/comment-page-2#comment-60636 The People’s Scrum « Agile Anarchy Sun, 06 Dec 2009 06:08:36 +0000 http://blog.mountaingoatsoftware.com/?p=24#comment-60636 [...] and in the process usually teach Planning Poker.  Planning Poker is a tool.  The story template [ref] designed by Mike Cohn is a tool.  Likewise, a talking stick in a stand up meeting, a timeline in [...] [...] and in the process usually teach Planning Poker.  Planning Poker is a tool.  The story template [ref] designed by Mike Cohn is a tool.  Likewise, a talking stick in a stand up meeting, a timeline in [...]

]]> By: Writing user stories for agile (Scrum) projects – revisited http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template/comment-page-2#comment-60498 Writing user stories for agile (Scrum) projects – revisited Fri, 04 Dec 2009 15:19:22 +0000 http://blog.mountaingoatsoftware.com/?p=24#comment-60498 [...] refined the template I use for writing user stories. I am still inspired by Mike Cohn and I used his template for user stories as a base for my own [...] [...] refined the template I use for writing user stories. I am still inspired by Mike Cohn and I used his template for user stories as a base for my own [...]

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template/comment-page-2#comment-55812 Mike Cohn Sun, 08 Nov 2009 15:56:50 +0000 http://blog.mountaingoatsoftware.com/?p=24#comment-55812 Hi Seetharamu-- The best thing is to leave the stories as large epics as long as possible. This keeps most dependencies within a single epic and so they aren't a problem. Other dependencies can exist and you can handle those by annotating the card the story is written on. I don't bother annotating "natural dependencies"---if we assume that we will add widgets to the database before deleting them, I don't annotate the delete story with "assumes adding widgets is done first." Sometimes that natural assumption will be false but in probably 99% of all cases that just means some of the effort estimate moves directly from one story to the other. As for a "story architecture" the way I think about this is really just as a Feature Breakdown Structure (epics at the top, smaller features below). Sometimes a mindmap is useful and there are good tools for this. Jeff Patton calls a similar approach a story map but he brings time into his maps. You may want to look at those. Personally, I leave time out in the early stages because it's impossible to prioritize (correctly) without knowing the cost and when I'm writing stories I don't yet know the cost of each. Hi Seetharamu–
The best thing is to leave the stories as large epics as long as possible. This keeps most dependencies within a single epic and so they aren’t a problem.

Other dependencies can exist and you can handle those by annotating the card the story is written on. I don’t bother annotating “natural dependencies”—if we assume that we will add widgets to the database before deleting them, I don’t annotate the delete story with “assumes adding widgets is done first.” Sometimes that natural assumption will be false but in probably 99% of all cases that just means some of the effort estimate moves directly from one story to the other.

As for a “story architecture” the way I think about this is really just as a Feature Breakdown Structure (epics at the top, smaller features below). Sometimes a mindmap is useful and there are good tools for this. Jeff Patton calls a similar approach a story map but he brings time into his maps. You may want to look at those. Personally, I leave time out in the early stages because it’s impossible to prioritize (correctly) without knowing the cost and when I’m writing stories I don’t yet know the cost of each.

]]> By: Seetharamu http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template/comment-page-2#comment-55201 Seetharamu Wed, 04 Nov 2009 09:01:25 +0000 http://blog.mountaingoatsoftware.com/?p=24#comment-55201 Mike, Highly informative blog to go through... I am wondering how we can depict the dependencies/linkages between User Stories. Do you recommend having a kind of 'Story Architecture' before we start breaking down a requirement? Mike,

Highly informative blog to go through…

I am wondering how we can depict the dependencies/linkages between User Stories. Do you recommend having a kind of ‘Story Architecture’ before we start breaking down a requirement?

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template/comment-page-2#comment-54141 Mike Cohn Wed, 28 Oct 2009 12:32:00 +0000 http://blog.mountaingoatsoftware.com/?p=24#comment-54141 Hi Nicolas-- I say that the so-that clause is optional for two reasons: <ul> <li>Sometimes the value is obvious. The value of the story "As a forgetful user, I can request a password reminder" is probably pretty apparent. If it's not, the value will come out in the conversation to the perhaps 1-2% of team members who can't figure out why we would want that feature.</li> <li>I've found that as a consultant I need to be careful in mandating things. If I mandate something, I am doing so for all companies with whom I work or for everyone who comes to one of my agile training classes or reads a book. That would be mandating things to a lot of people whose project context I don't know! ;)</li> </ul> So, I usually offer the guideline that a good product backlog will be about 90% user stories and about 90% of those will have good, clear so-that clauses. (Since I'll get asked: the 10% of the backlog that isn't user stories is just stuff someone put on the product backlog that probably could be turned into a true user story but wasn't worth it. For example, "Upgrade developer laptops to Windows 7" would not bother me on a product backlog today but we certainly could use the template to write that if we wanted.) Hi Nicolas–
I say that the so-that clause is optional for two reasons:

  • Sometimes the value is obvious. The value of the story “As a forgetful user, I can request a password reminder” is probably pretty apparent. If it’s not, the value will come out in the conversation to the perhaps 1-2% of team members who can’t figure out why we would want that feature.
  • I’ve found that as a consultant I need to be careful in mandating things. If I mandate something, I am doing so for all companies with whom I work or for everyone who comes to one of my agile training classes or reads a book. That would be mandating things to a lot of people whose project context I don’t know! ;)

So, I usually offer the guideline that a good product backlog will be about 90% user stories and about 90% of those will have good, clear so-that clauses. (Since I’ll get asked: the 10% of the backlog that isn’t user stories is just stuff someone put on the product backlog that probably could be turned into a true user story but wasn’t worth it. For example, “Upgrade developer laptops to Windows 7″ would not bother me on a product backlog today but we certainly could use the template to write that if we wanted.)

]]> By: Nícolas Iensen http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template/comment-page-2#comment-54093 Nícolas Iensen Wed, 28 Oct 2009 04:14:23 +0000 http://blog.mountaingoatsoftware.com/?p=24#comment-54093 Hi Mike! You wrote "While I consider the so-that clause optional". I totally disagree with that. Actually, I consider the "so-that" clause the most important part of a story, because this is the VALUE! Why keeping a story on the backlog, if there is no value on it??? Great article man! Cheers Hi Mike!

You wrote “While I consider the so-that clause optional”.

I totally disagree with that. Actually, I consider the “so-that” clause the most important part of a story, because this is the VALUE!

Why keeping a story on the backlog, if there is no value on it???

Great article man!

Cheers

]]> By: BDD em Java na prática, com JBehave « Keep Thinking http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template/comment-page-2#comment-52797 BDD em Java na prática, com JBehave « Keep Thinking Fri, 16 Oct 2009 16:29:37 +0000 http://blog.mountaingoatsoftware.com/?p=24#comment-52797 [...] o padrão de stories sugerido por Mike Cohn (e também encorajado pelo próprio Dan North), nosso cenário poderia ser algo como: Title [...] [...] o padrão de stories sugerido por Mike Cohn (e também encorajado pelo próprio Dan North), nosso cenário poderia ser algo como: Title [...]

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template/comment-page-2#comment-52581 Mike Cohn Thu, 15 Oct 2009 04:27:52 +0000 http://blog.mountaingoatsoftware.com/?p=24#comment-52581 Thanks, Sergio. I appreciate that. I really try to answer all the questions here. Thanks, Sergio. I appreciate that. I really try to answer all the questions here.

]]>