57015Re: [scrumdevelopment] User Stories, APIs and data feeds
- Jul 11, 2013Cass,
Agreed that there are a couple of "small cases" where the template helps -- for a little while. The vast majority of cases I've seen, it hurts, either because people spend too much time trying to force fit the template, or get into this mode that the template/sentence *IS* a user story. Thinking the template/sentence *IS* a user story is the biggest trap of all IMO... something I wrote about several years back:
http://scrumcrazy.wordpress.com/2011/01/05/user-story-traps/ (See trap #1 and #8)Btw, I fell into many of those traps -- which is why I can write so freely and well about them! :-) Our fellow lister and co-inventor of User Stories Ron Jeffries "schooled" me on many a thread... forever grateful for that man's patience.-------
Professional Scrum Trainer
From: Cass Dalton <cassdalton73@...>
Sent: Wednesday, July 10, 2013 12:24 PM
Subject: Re: [scrumdevelopment] User Stories, APIs and data feeds
I always saw the "As a... I want... Because..." as "training wheels" for learning user stories. Once you learn how to ride, they get in the way. But they are really helpful to learn how to ride a bike in the first place.The template mentioned by the OP may get in the way when you're a seasoned agile practitioner, but when you are first learning about user stories, especially if you're coming from a "The system shall..." culture, being forced to specify the user, specify the desired user's action (vs a desired system characteristic), and specify WHY the user wants to perform that action really helps get you out of the requirements mentality.On Tue, Jul 9, 2013 at 3:48 PM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:Ram,
What you mentioned is *a* user story template, not "the template of a user story". The user story practice itself does not require or even suggest the template strategy. IMO, the template itself most often harms the true intention of the user story practice, but that's probably off topic.
Having said that, why do you need to use the template? It sounds like maybe you're having trouble expressing the business need in business terms, which is pretty smelly in its own right... Why is this? What kind of waste is being created by not understanding the business intention? Where is the PO in all of this? Why doesn't he/she understand the business needs?
Yes, the end user themselves may not understand the underlying value of the feed... but someone should... or you shouldn't be wasting the company's money developing features of suspect value.
I don't think that the root problem is with the template or the user story practice.-------
Professional Scrum Trainer
From: Ram Srinivasan <vasan.ram@...>
To: "scrumalliance@..." <scrumalliance@...>; "firstname.lastname@example.org" <email@example.com>; "firstname.lastname@example.org" <email@example.com>; "firstname.lastname@example.org" <email@example.com>
Sent: Monday, July 8, 2013 9:40 PM
Subject: [scrumdevelopment] User Stories, APIs and data feeds
We all know the template of a user storyAs a <role>I want <feature>So that <benefit>or something similar.It is straightforward if the "consumer" of a feature is well defined (say a shopper in an e-commerce site). This format also appeals better when we are asking developers to develop a "thin" vertical slice.Consider a trading system or data feed/api (like GDS) where the goal of the application (say API-app) is to consolidate different data and give it to other third party "systems" ( which can be consumed in a multitude of ways by different users of different "systems". These third party systems are not within the same organizational boundaries). The end user may not even realize the benefit of the underlying API/feed (from API-app) because the "system" obscures the presence/absence of a particular feed/data. The development team which develop the feeds/apis can only make a vague guess on who might be using the feeds/apis and the benefits that they may be looking for.Would it still make sense to write user stories (for API-app) in "As a <role> ..." format, where role is the ultimate end user of an api/feed (marshalled through an intermediate "system")? What would be the benefit? And drawback?What other approaches would make more sense when the actual consumer of a particular data feed/api is separated from the teams (generating the feeds/apis) by multiple "value streams"?Thanks,
- << Previous post in topic Next post in topic >>