Re: Bad initial user stories

Re: Re: Bad initial user stories

Re: Re: Bad initial user stories

Re: Bad initial user stories

Cass,

From your perspective you do have an interesting issue. Story points represent the team's understanding
of how much effort is required to deliver a story. Teams can estimate some time in advance of delivering the
story - i.e before the requirements are fully understood. From what I have read Backlog items that will not
be delivered imminently tend to be given higher story point values initially. But in subsequent Sprint
Planning or Product Backlog grooming sessions are given more accurate values as the Backlog item is
better understood. In your case it sounds as though you team are providing optimistic estimates early on
then revising them up as more detail emerges. Product Backlog grooming should break those fuzzy epics
into some smaller more tangible user stories. My immediate suggestion
  for you EV - cash dilemma would be to get the team thinking about the tasks required to deliver the User Story
even during the early stages as this might flush out some early complexities that might have been
overlooked. You could also the Sprint Retrospective as an opportunity for the team to reflect on their
initial estimates compared to those identified in Sprint Planning as it will allow the team to come up with
their own improvements to this problem.

On a side note, if you are adding stories as you go, are they added to the Product Backlog or Sprint Backlog. If
it's the PB you're OK as they can be estimated during the regular cycle of grooming and planning. Also, Ken
Schwaber's Scrum Book (the 2004) has some advice on reporting Scrum projects - based around delivered
features rather than time spent etc.

I hope these ramblings help :)

Kind Regards,

Jon

--- In scrumdevelopment <at> yahoogroups.com, Cass Dalton <cassdalton73 <at> ...> wrote:
>
> Thank you to every one who responded with usable content...
> 
> Ron,
> You are right on the mark with everything.  We are guilty as charged, but
> that's part of what I'm trying to change in our organization.  It's not
> easy.  Developers are used to just working what they are told to work and
> how they are told to work.  We have a Rockstar/Hero culture and it is
> difficult to build a real team in that environment.  However, it is the
> environment I'm in, and a small group of us are committed to changing it as
> much as we can.  So while I hear everything you're saying, my issues still
> exist and I look to this forum for any advice on how to make those inroads.
> I guess part of my problem is that I don't think I really understand what
> backlog grooming is.  I intuitively understand that the questions I asked
> really relate to grooming, but I'm stuck on what that actually means.  When
> I go to groom the backlog and I encounter the situation I described, what
> do I do?
> 
> Jon,
> I think the part about not using stories for EV was what I needed to hear.
>  Especially in this rocky start to working agile.  Do you have a
> suggestion?  We are a DoD contractor and we have to give "estimates" to our
> customers and no amount of discussion or negotiation keeps them from
> being commitments.  That's just how their contracts office works.  We give
> them an estimate, and they get exactly that amount of money.  They are not
> against an agile approach, but I'm still fuzzy on how I can report an
> effective EV metric when the initial stories are mostly fuzzy epics.  We
> tend to add stories or issues to the backlog as we go, so it's confusing to
> try and report status up based on user stories.
> 
> Alan,
> Thanks for the tip on the user story book.  Just got it in from Amazon and
> it looks very helpful so far.
> 
> On Tue, Jun 12, 2012 at 8:29 AM, Charles Bradley - Scrum Coach CSP CSM PSM
> I <chuck-lists2 <at> ...> wrote:
> 
> > **
> >
> >
> > Well said, Jon!  I also ++1 to doing backlog grooming(and all of Ron's
> > excellent advice).  Not realizing that backlog grooming is a required
> > component of Scrum is one of the more common mistakes I'm noticing in
> > recent years.  It may be because the Scrum Guide switched this practice
> > from optional to essentially required in the July 2011 Scrum Guide.  Note
> > also that the "format" of backlog grooming is not specified in the guide
> > (it can be formal or informal, but my strong preference for Shu/Ha teams is
> > 1-2 hours weekly).
> >
> > <light self promotion>
> > Here are my tips on Backlog Grooming (these articles need some
> > streamlining, but you will probably get the gist):
> > http://www.scrumcrazy.com/space/content?tag=backlog+grooming
> > </light self promotion>
> >
> > -------
> > Charles Bradley
> > http://www.ScrumCrazy.com
> >
> >
> >   ------------------------------
> > *From:* Jonathan <jon_eversett <at> ...>
> > *To:* scrumdevelopment <at> yahoogroups.com
> > *Sent:* Monday, June 11, 2012 3:41 PM
> > *Subject:* [scrumdevelopment] Re: Bad initial user stories
> >
> > Hi Cass,
> >
> > 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 said 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.
> >
> > Regards,
> >
> > Jon
> >
> > --- 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?
> > >
> > > Thanks
> > > Cass Dalton
> > >
> >
> >
> >
> >
> > ------------------------------------
> >
> >
> > To Post a message, send it to:  scrumdevelopment <at> ...
> > To Unsubscribe, send a blank message to:
> > scrumdevelopment-unsubscribe <at> ...! Groups Links
> >
> >
> >
> >
> >
> >    
> >
>

------------------------------------

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 to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> 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/