Loading ...
Sorry, an error occurred while loading the content.

Story sizes at inception stage

Expand Messages
  • stugib_2000
    Hi, I work as a business analyst in a company that is in its early transition stage to agile. I m a self-taught agile enthusiast and have a certain amount of
    Message 1 of 45 , Jan 14, 2012
      I work as a business analyst in a company that is in its early
      transition stage to agile. I'm a self-taught agile enthusiast and have a
      certain amount of experience of writing requirements as user stories,
      and maintaining/grooming backlogs, from previous roles, but my knowledge
      and experience is largely Scrum-based and mostly from Mike Cohn's books,
      plus others. We currently have a consultancy helping us with our
      transition that are quite fixed (somewhat cult-ish IMHO!) in their ways
      of working, but are historically XP-based. I'm having some arguments
      with them at the moment, which I'd like your advice on to see if it's
      just differences between agile models, or they're being too fixed on
      their own ways, or whether I've just got the wrong end of the stick with
      too much theory and not enough practical experience.
      My question is around the size of stories in the early phase of the
      project - the initial product backlog as I'd call it from my Scrum
      knowledge. We have had a 2 hour kickoff workshop with the stakeholders
      sketching out the application to agree a broad scope, feature set and
      priorities. I'd expect this application is of the size that would take a
      4 developer team 6-8 week long iterations to develop. So not a massive
      project, but I think the question is still relevant regardless of
      project size, possibly more so with a bigger project.
      __MY WAY__At this point I would usually expect to break down the
      features a bit further and do a bit of analysis to make sure we'd
      covered everything needed, but these would probably still mostly be
      epics (e.g. "I want to be able to buy a book" rather than "I want to be
      able to add a book to my basket", "I want to be able to update the
      quantity of books in my basket" etc even if we had made some assumptions
      as to that was how it would work). If we estimated at this stage I'd
      expect a mix of 5, 8 point stories (assuming a 1/2/3 point story would
      be do-able within a day or two) and wouldn't necessarily be concerned if
      we had a 13 or 20 point story for the lower priority items, as long as I
      could explain roughly what it involved. Our estimates would be good
      enough to say whether it was a 10-12 iteration project rather than a 6-8
      iteration project, but we wouldn't want to commit to the lower end of
      those ranges because I'd expect more stories to emerge which would
      change them. It would be enough to get commitment to continue with the
      project though, although I recognise that may be a peculiarity of my
      company who is generally happy to continue with internal developments on
      the basis of a rough estimate.
      Once the backlog was prioritised I would break down the highest priority
      epics into small stories for the next iteration or two (we're using 1
      week iterations) discussing these with the product owner and elaborating
      the story to write acceptance criteria. I'd repeat this iteratively
      throughout the project so <=iteration sized stories were available in
      time for the start of the iteration but not necessarily before. The
      'DEEP' acronym
      klog-deep/> ) has always summarised this concept well for me in my own

      __CONSULTANTS WAY__I'm being asked on the basis of the workshop to
      create an initial list of stories which must all be <=iteration sized
      stories. They don't necessarily even recognise the concept of an epic.
      They recognise there will be new stories added and re-prioritised, and
      they will only be elaborated with the acceptance criteria written
      just-in-time, but still expect small stories up front.
      They also think that the sketched mockups we did in the workshop to
      explore what the requirements were should have been detailed enough to
      commit to an interface design, but that's a different topic.
      __QUESTION__Now to me, this goes against what I've always read, because
      this way would:a) could take quite a lot of up-front analysis to
      identify stories of that granularity, and would also get into assuming a
      design for the product (e.g. who says we're using a basket metaphor?) in
      order to do this.b) is potentially wasteful because those lower priority
      features may never be developed and need those smaller stories.
      So in your experience, what size of backlog items would you expect on
      your backlog before the first development iteration? And if you agree
      with the consultant's approach, what steps and how much effort do you
      think should be expended to get to that list of stories?

      [Non-text portions of this message have been removed]
    • Seyit Caglar Abbasoglu
      Very nice stuff. Thanks. I m not planning to be a coach. However those are good guidelines for anytime someone wants to help another. 2012/1/19 George
      Message 45 of 45 , Jan 19, 2012
        Very nice stuff. Thanks. I'm not planning to be a coach. However those are
        good guidelines for anytime someone wants to help another.

        2012/1/19 George Dinwiddie <lists@...>

        > **
        > I like this question for coaches from Esther Derby
        > (http://www.estherderby.com/2011/02/are-you-ready-to-coach.html)
        > "*Are you open to other approaches?* You may have a very clear idea of
        > how to accomplish the work or handle the interaction. But is it the only
        > way? In most situations, there are many reasonable and acceptable paths
        > to success. If you find yourself expecting things to be done a certain
        > way, ask yourself if that way is simply your preference and not the only
        > correct method. Help the person you are coaching think through different
        > options and discuss the pros and cons of each approach. Then let the
        > person choose the one that fits best for him or her. Team members gain
        > capability when they develop based on their own thinking modes,
        > strengths, and talents."
        > - George
        > On 1/19/12 10:23 AM, George Dinwiddie wrote:
        > > Seyit,
        > >
        > > On 1/19/12 6:46 AM, Seyit Caglar Abbasoglu wrote:
        > >> I agree the example was not matching perfectly. And I completely agree
        > on
        > >> your consultant definition.
        > >>
        > >> However I still believe the idea behind the example is still valid.
        > There
        > >> is a professional (mechanic/consultant) doing his job in the way he
        > knows,
        > >> and we're saying he's doing it wrong, while he's absent to defend his
        > ways.
        > >> Perhaps he would present the context in such a different way than
        > Stuart,
        > >> that we would think he's doing the right thing. (Though I doubt it)
        > >
        > > I think the example is not valid. It would be valid if the company had
        > > brought in a manager, and that manager was managing the way he knew
        > > best. Consulting is different in nature. Coaching is a specific type of
        > > consulting with the express intent of helping the coachee better their
        > > skills.
        > >
        > > - George
        > >
        > >
        > >>
        > >> I still believe the real problem in that context is a trust and
        > >> communication issue. Perhaps a better solution would be to do it by
        > >> Consultant's way, see the outcome and help to improve it 'slowly',
        > instead
        > >> of saying directly that 'he's doing it wrong'
        > >>
        > >> 2012/1/18 RonJeffries<ronjeffries@...>
        > >>
        > >>> **
        > >>>
        > >>>
        > >>> Hi Seyit,
        > >>>
        > >>>
        > >>> On Jan 18, 2012, at 1:46 PM, Seyit Caglar Abbasoglu wrote:
        > >>>
        > >>>> Consider my car is not giving the performance I expected from it and
        > I go
        > >>>> to a mechanic to ask his help.
        > >>>
        > >>> Your example is not apt. The consultant is not a mechanic who is going
        > to
        > >>> fix the car. The consultant is someone who is going to educate the
        > team.
        > >>>
        > >>> The consultant should encourage people to study and think on their own,
        > >>> and help them to coordinate the various ideas they will come up with as
        > >>> they dig into the subject.
        > >>>
        > >>> Ron Jeffries
        > >
        > --
        > ----------------------------------------------------------
        > * George Dinwiddie * http://blog.gdinwiddie.com
        > Software Development http://www.idiacomputing.com
        > Consultant and Coach http://www.agilemaryland.org
        > ----------------------------------------------------------

        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.