Breaking down stories
To what level should stories be broken down? We have a story that simply says "ABC v2.0.0," where ABC is the name of the application. If written in the normal format, it would say something like "As an ABC user, I can have all the bugs fixed and all the enhancements made, so that life will be good."
I think that's way too big. I think having huge stories like this is the main reason we only completed 1 out of 110 points last sprint. But how far should they be broken down?
Is a story like "As an ABC user, I can have the typo on the profile page fixed, so that I can have a better user experience" too small?
Ragesh,
A sentence like the ones you mentioned are not a user story.
See trap #'s 1 and 8 here:
http://scrumcrazy.wordpress.com/2011/01/05/user-story-traps/
See here for a better understanding of what a user story really is:
http://www.scrumcrazy.com/User+Story+Basics+-+What+is+a+User+Story%3F
It is generally best if user stories are broken down into a size that can be completed in 2-3 days. More here:
http://www.scrumcrazy.com/The+ScrumCrazy.com+User+Story+Maturity+Model
User stories have a specific format, designed to help the author be descriptive and the reader (a developer) to take action:
“As a [persona], I want to [do something] so that I can [derive a benefit]”
If you’re the product person, your job is the fill in the (orange) blanks. The persona is a vivid, humanized, yet operational description of your user. The ‘[do something]‘ is a some action you assume the user wants to do, and the ‘[derive a benefit]‘ clause is a statement of why you've assumed the user persona wants to do what you describe. The [derive a benefit] clause is the most neglected by most creators of agile user stories and yet the most important. The reason why it’s so important is that this is where you’re saying why the feature you’re proposing to build makes sense.
Once you have stories that tie back to strong, validated customer discovery, your job is to organize this material into compelling narratives your development team can understand. There are a few ways to do this, but you want to make sure your compiled personas and problem scenarios are highly visible. Personally, I use this Venture Design Template which ties those items together. Presentations are also good, particularly if the focus is you describing what it was like observing the customer. The key thing is to spur interest and discussion with your developers about your stories, a discussion that drives toward more customer-relevant implementations. If no one ever says ‘I just built what you said’ then you know you did a great job.
Charles, interesting. Is this your opinion, or is this definition generally accepted?
We do have conversations, but they usually don't happen until the developer is working on a story. And we do have acceptance tests for some stories, but not all.
> To what level should stories be broken down?
Investing in a user story is a bit like investing in the stock market...it is important to stake no more than you are prepared to lose.
In other words, if you have a large user story you must bear in mind the increased risk of non-completion. Smaller stories exhibit greater liquidity and throughput. It is no longer a matter of all or nothing, so the risk exposure is concomitantly lower. The limiting factor on smallness is the value provided to the Product Owner, as each story must be substantial enough to release genuine value..
> User stories have a specific format, designed to help the author be descriptive and the reader (a developer) to take action:
This is not true. The only "specific format" of User Stories is that they have a card, a conversation, and confirmations. The sentence template was something added later by some guy, and it has serious drawbacks (and a couple of small, infrequent advantages).
Card, Conversations, Confirmations:
http://xprogramming.com/articles/expcardconversationconfirmation/
> Charles, interesting. Is this your opinion, or is this definition generally accepted?
Generally, people don't understand the user stories practice. I learned directly from the guy who co-created the user story concept. The same guy edited and approved the article that I wrote on the Agile Atlas. The article is arguably the most credible article about user stories on the internet.
http://agileatlas.org/articles/item/user-stories
I'm not sure "generally accepted" is a good standard. It was "generally accepted" for many centuries that the world was flat. "Truth" and "facts" might be better standards.
I agree with Charles. The most important point is the conversation, not really in the format. The format is suppose to trigger conversation.
Charles, unfortunately truth and facts don't really work when we have to convince management of something. We need something official we can point to that says we're doing it wrong.
A few months ago you linked to Jeff Sutherland's article about why story points are better than hours (http://scrum.jeffsutherland.com/2010/04/story-points-why-are-they-bette…). Great article. Unfortunately, the whole world thinks you're supposed to use hours, and this one post isn't going to overturn that.
Same with user stories - everyone thinks a story is just a sentence in a particular format, and it's going to be really hard to shake that perception.
Ragesh,
The Agile Atlas is about as official as you can get -- it is pretty much the official body of knowledge for the Scrum Alliance. Ron Jeffries, **the guy who created the User Story practice**, is about as official as you can get.
How "more official" do you want it to get? Are you waiting on a sign or proclamation from a deity? :-)
Charles
Charles, it still comes down to one post on a blog I hadn't heard of. Not a big deal, I was just curious about how much support this idea has. Sounds like maybe it's a case of VHS vs Beta (your definition sounds better but less popular).
The points vs hours thing is a much bigger deal to me. Instead of just writing a post complaining about what a horrible practice it is to estimate stories in hours, I wish that Jeff Sutherland had put this in the Scrum Guide to make it official instead of a matter of preference.