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

Re: [XP] Story sizes at inception stage

Expand Messages
  • M. Manca
    ... Just to understand better my background: I normally develop embedded software and software on PC or PC-like but always related to embedded and industrial
    Message 1 of 45 , Jan 14, 2012
      Il 14/01/2012 19:23, stugib_2000 ha scritto:
      > 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 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.
      Just to understand better my background: I normally develop embedded
      software and software on PC or PC-like but always related to embedded
      and industrial applications. About my agile practices: like you I
      started with Scrum then I used XP and Scrumban (scrum + kanban).
      Actually my way to do agile is a little bit changed to "adjust"
      practices to my reality where behaviour driven development and kanban
      board are the most effective practice and tool.
      > 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.
      Ok, when you acquire requirements during a meeting or interviews with
      customers and stackholders you will write somemthing on the front of a
      card that could be a story (or an epic) and on the back of the card you
      may take some notes to detail better what written on the front. When you
      are writing the card if you haven't a good product knowledge you
      couldn't understand if your front card is a story or an epic. Only
      having a good/discrete knowledge of the product you could distinguish
      stories and epics.
      > 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 don't know the complexity of your project but 2 hours is a very short
      time to do all these things, expecially to define priorities. Of course
      for stakeholders may be a long time if they know very well the product
      but couldn't be the same for you and your team. So, 2 hours may be the
      right time to tell about the product in general terms to help you to
      understand what is, what it means to the stakeholders, what are the new
      parts inside it, what are non functional requirements and so on but I
      can't imagine a detailed analisys to define functional requirements made
      in 2 hours.
      > 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.
      So it isn't a little application.... in my experience this means that
      you could expect to have 24-40 stories. But this is a reverse
      calculation based on your estimate and supposing it is correct.
      > __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).
      I think that epics aren't useful to estimate the effort, so I would use
      a divide and conquer strategy: every time you suspect that a card text
      could hidden an epic instead of a story try to detail/divide it. If I am
      able to divide the original card text in 2 or more parts then originally
      it was an epic.
      > 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.
      I agree with this point.
      > 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.
      In general terms it is ok but is it ok also for your company and your
      customer? 4 more weeks means also more money, so effort estimates
      accuracy may have a big impact.
      > 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.
      It is quite common. A lot of companies doing XP or SCRUM need also rough
      estimates to decide to do or to buy.
      > 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.
      I really think that you have no material to put on your backlog if you
      haven't a set of stories. So it is correct to refine the cards content
      to divide epics in stories.
      > The
      > 'DEEP' acronym
      > (http://www.romanpichler.com/blog/product-backlog/making-the-product-bac\
      > klog-deep/
      > <http://www.romanpichler.com/blog/product-backlog/making-the-product-backlog-deep/>
      > <http://www.romanpichler.com/blog/product-backlog/making-the-product-bac\
      > klog-deep/
      > <http://www.romanpichler.com/blog/product-backlog/making-the-product-backlog-deep/>>
      > ) has always summarised this concept well for me in my own
      > head.
      Personally I don't like to have deep backlogs. Also when I can't have
      the customer at my desk or he can't accept that I and my team are at his
      desk I tell to him a lot about every day. So, at beginning I think that
      I write rogue stories, I try to don't write epics at all (the only
      exception is for optional features or for features that will be detailed
      in a second step). Then at 1st iteration I will develop highesst
      priority stories and put only them on the backlog; all the other stories
      have to stay on a different place (think to a box under the backlog area
      if you use a real dashboard).
      > __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.
      Personally I agree with consultants.
      > 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.
      I also agree with this point if small stories have the highest priority,
      if they haven't I don't agree.
      > 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.
      I don't agree so much because I think that 2 hour is a too short time to
      detail a GUI.
      > __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.
      I think that you have to discuss this point with consultants and also
      your team. First of all I really think is quite impossible in just 2
      hours define the priority of a 24-36 stories set and then I think you
      may just know the stories most important for your stakeholders.
      > So in your experience, what size of backlog items would you expect on
      > your backlog before the first development iteration?
      It is not important at all. It is very important that you and your team
      have a good general vision and knowledge of the product before the 1st
      iteration so you can take you card set and define what cards have the
      higher priorities. Then detail better these cards (generally the card
      number increase during this phase) and put in the backlog for the 1st
      iteration only the number of card you are able to do in that iteration
      and the remaining in the product backlog. If you will finish the cards
      before the end of the iteration you may simply take from the product
      backlog some other cards (following priority order) and go on in the
      same way.
      > 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?
      I think you need to be sure you don't have any epic on your cards. So, I
      can't say how much time you will need but you can't have any epic on
      your backlog so you need to refine all cards that may hidden an epic.
      > ThanksStuart
      > [Non-text portions of this message have been removed]

      [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.