Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Who Wants This User Story?
Posted by Dan Puckett on Nov 01, 2010
The standard user story format is, "As a role, I want goal/desire so that benefit." For some user stories, however, this straightforward template goes haywire when it comes to figuring out who should be listed in the role field.
For example, in a recent thread on the Scrum Development mailing list, Kevin Krac asked about the following real-life user story:
The Product Owner has thought up a story which is about changing the telephone number where the customer can call after making a purchase. Right now, Marketing's dept. phone number is listed in the e-mail sent out to the customer, but the Product Owner thought it would be wiser to put there a Sales representative phone number instead.
Who should go in the role field when formulating this particular user story? The Product Owner? A member of the marketing department? A sales representative? Someone else?
Why include a role field in user stories at all? Don MacIntyre gives one reason: "I've found that clearly identifying the role as the beneficiary helps Product Owners come up with a clear value proposition—which in turn helps them to prioritize the story." In this story, though, it isn't clear yet who benefits when the development team completes it.
Ron Jeffries sees little value in adhering to the standard story form:
What is on the card is hardly relevant at all: I would favor something like "Replace Marketing phone number with client sales rep number."[...]
Thinking is important. Choosing the most valuable stories is important. Explaining to the team what is finally decided is important. Having concrete tests to be sure it works is important.
What is written on the card is less important than any of those.
Mike Cohn, however, sees some advantages in the standard user story format. The advantages he sees include:
- Placing user stories in the first person ("As a ... I want ...") helps developers and others identify with the beneficiaries of the work they are doing.
- Structuring all the stories the same way helps the product owner prioritize among them by removing the need to mentally parse the text of each user story individually.
To make the standard format work for non-standard stories, Mike Cohn has a couple of tips:
A good user story can be about any stakeholder of the system. And the story can just as easily be something other than "want" as in "As a shopper, I am shown complementary products when I start to check out." Or, "As a user, I am forced to change my password every 90 days." So not all stories need "want" in them.
Filling in blanks in a user story template, however excellent that template might be, will not do the hard work that needs to be done. The keys to user story success are, as Ron Jeffries puts it, "Card, Conversation, Confirmation". That is, make a card with just enough text to identify the requirement (a "user story"), have just enough communication between the customer and the programmers to be able to code that requirement successfully, and confirm the result of the completed work by means of an acceptance test.
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Deliver quality code quicker with "Go" Agile release management
Systems Engineering for Dummies eBook
Five Key Practices to Agile ALM
Branching & Merging Efficiently: A Guide to Using Process-Based Promotional Patterns
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
The standard template still works here - if you get the user right!
by
Douglas Stein
Posted
Re: The standard template still works here - if you get the user right!
by
Ravichandran J.V.
Posted
Re: The standard template still works here - if you get the user right!
by
Morgan Ahlström
Posted
Re: The standard template still works here - if you get the user right!
by
James Richardson
Posted
Process Madness
by
Chris Matts
Posted
Is it OK if I disagree with Ron Jeffries? :-)
by
Assaf Stone
Posted
-
"As a customer, I want to know whom to call if I have any questions about my new purchase so I can enjoy what I just spent my hard-earned money on!"
It's only a problem because you kept thinking about company staff as the users for the story. Properly formulated, this story will cause the product owner to understand if there are other things (besides code) that the company needs to do to satisfy new customer needs. For complex products, you might introduce the customer to his account manager (on a customer retention team) or invite the customer to a free webinar about how to get the most out of the purchase. For simpler purposes you might point the customer to "support" (whether fulfillment or technical).
The larger point about Card/Conversation/Confirmation is valid - the goal in writing a story is to identify something of value that is simple, implementable, and unambiguous. The accumulation of many positive "microtransactions" described by the stories build a relationship with the users and the system so it's something they enjoy instead of endure. -
Yes, the moment the user perspective is visible a story begins to make sense. The product owner was trying to think from his perspective and not from the user's perspective.
-
Hmmmmm.
So the problem is with conforming to the standard Agile format. Hmmmm. I favour a statement "People over Process". I feel a bit dirty saying it, but "I agree with Ron". ;-)
In actual fact, what you may be really encountering is that you have two levels of stories. One for stakeholders and one for users. Liz Keogh talks about Stakeholder Stories ( lizkeogh.com/2010/02/02/theyre-not-user-stories/ ) instead of User Stories. Anthony Marcano then showed the hierarchy of Stakeholder Stories and User Stories ( www.testingreflections.com/node/view/8556 ).
Chris -
I'm not sure that we need to adhere to the template at all times but I agree with the above comment. When we have trouble stating a user story according to the template, it's usually because we've lost focus on the need and began looking at the solution instead.
There was a great post on DZone about six months ago on Fixing the Cause-Effect Trap in User Stories, agile.dzone.com/news/fixing-cause-effect-trap-user . I think that doing the suggested 5-Whys excercise on our requirements is a great way to help us once again to start focusing on what's important. When we've identified the actual need, there's usually a role and a reason within reach as well.
BR
Morgan -
Of course you dont need to adhere to the template at all times! Thats the whole fing point.
-
While the process is undoubtedly less important than people, and what's on the card is less important than thinking, explaining and testing, as Ron said, I completely disagree on the importance of the role part in the user story.
If the PO can't decide who benefits/needs this story, it is often a clear indication that the story might not be useful to anybody; It might be that the PO is a victim of what our team calls "Featuritis".
A PO who is stuck on the role should not ignore the role because it is too hard, and "people are more important" and the card is not what is important; The PO should think, and explain who cares about the story and why!
6 comments
Watch Thread Reply