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

Re: [XP] Story sizes at inception stage

Expand Messages
  • George Dinwiddie
    Stuart, On 1/14/12 1:23 PM, stugib_2000 wrote: [snip] ... Sounds good so far. How many chunks (features, epics, stories, whatever you want to call them) of
    Message 1 of 45 , Jan 14, 2012
    • 0 Attachment
      Stuart,

      On 1/14/12 1:23 PM, stugib_2000 wrote:
      [snip]
      > 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.

      Sounds good so far. How many chunks (features, epics, stories, whatever
      you want to call them) of functionality were identified in this
      sketching out? Are some of them WAY bigger than others? Are some of
      them a mix of high priority and lower priority functionality?

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

      What benefit would you get from estimating whether this was a 10-12
      iteration project rather than a 6-8 iteration project? Would you still
      get the same value from that benefit if you made that estimate 2 or 3
      iterations into the project?

      > 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
      > (http://www.romanpichler.com/blog/product-backlog/making-the-product-bac\
      > klog-deep/
      > <http://www.romanpichler.com/blog/product-backlog/making-the-product-bac\
      > klog-deep/> ) has always summarised this concept well for me in my own
      > head.
      >
      > __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?

      I would take a more laid-back approach than what you or the consultant
      suggest.

      What's the barest minimum that vaguely represents the crux of the
      system? Start with that, and build your "walking skeleton." You can
      detail other stories as you go, but do make sure you keep the big
      picture of what's important in mind.

      - George

      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    • 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
      • 0 Attachment
        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.