From: Jonathan <jon_eversett <at> yahoo.co.uk>
To: scrumdevelopment <at> yahoogroups.com
Sent: Monday, June 11, 2012 3:41 PM
Subject: [scrumdevelopment] Re: Bad initial user stories
I too am trying to get to grips with the subtleties of User Stories and my first assumption is that the stories should be what a user wants i.e. focussed and worded based on the user's experience of an application.
Based on what you have listed it looks as though the sub-stories are the development tasks required to deliver the main story. As I sai
d earlier I am fairly new to this stuff but the essence of story decomposition is to break the requirements down into a number of sub-stories each of which is complete
in itself and delivers business value.
On a couple of other points ... Are you Backlog Grooming? If you are regularly finding that your 8 point stories are breaking down to 18 it may well be because the team does not have sufficient information when making the initial estimate. If the Backlog is regularly groomed to add detail then these sorts of issues may go away.
The fact that estimates for stories can change when the team know more about it makes it a bad candidate for EV metrics for management. Story points are best left for Estimation and forecasting.
Hope some of that is useful.
--- In scrumdevelopment <at> yahoogroups.com
Cass Dalton <cassdalton73 <at> ...> wrote:
> We are learning how to write good user stories, but my
> team consistently encounters the situation in
which we write what seems to
> be a simple user story, but when we go to pull it out for a sprint and
> analyze it, it suddenly feels complex and too big to fit in a sprint. I
> know this is a typical scenario, but I have questions about the logistics
> of this situation.
> Also keep in mind that I need to report some form of earned value to the
> bean counters, and I was planning on using story point burn down as a form
> of EV. Maybe that's not the right mechanism. If someone has a better
> suggestion, I'm interested in hearing it.
> Lets say you had a story about uploading a data file to a web service. At
> the beginning, this sounds easy, so you tentatively assign 8 points to it
> as part of the
initial release planning. (Insert discussion about the
> appropriateness of point estimation during pre-planning, but you have to
> have some idea of the
sum total complexity of the effort to know if you can
> meet the minimum expectations with your given schedule and budget). When
> the team is ready to work the story, they talk through the story and
> realize that it is made of a number of sub-stories:
> 1 - connect to the web service - 5 points
> 2 - upload file - 3 points
> 3 - convert file to usable common data format - 5 points
> 4 - save converted file to data store so that it can be used by back end
> processing - 5 points
> This can be interpreted either as an underestimation of the complexity of
> the original story or additional stories that weren't originally in the
> product backlog (or a combination). Either way, the complexity of a
feature appears to "explode" when you get around to working it. This
> probably gets better with experience, but management will be paying more
attention to inexperienced teams and tracking them more closely. So how do
> you explain this phenomenon to higher ups? What did we do wrong in this
> contrived example? How would we improve in the future?
> Cass Dalton
To Post a message, send it to: scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo
! Groups Links
<*> To visit your group on the web, go
Your email settings:
Individual Email | Traditional
<*> To change settings online go to: http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)
<*> To change settings via email: scrumdevelopment-digest <at> yahoogroups.com scrumdevelopment-fullfeatured <at> yahoogroups.com
<*> To unsubscribe from this group, send an email to:
; scrumdevelopment-unsubscribe <at> yahoogroups.com
<*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/