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

41790Re: [scrumdevelopment] Re: Sprint planning using team capacity and detailed tasks vs.story-level estimates

Expand Messages
  • Michael James
    Oct 8, 2009
      One thing I'll add: *too much* of a sense of urgency reduces
      creativity, according to outside observers grading the results (though
      the people in the study thought they were being more creative). There
      is an optimum level of anxiety for best performance, and most of us
      are wayyy above it already.

      I still prefer timeboxes and iterations, just want to de-stigmatize
      "failure" to get it all done, as the stigma can prevent learning.
      Take a failure bow, retrospect, and move on.

      --mj


      On 10/8/09, Roy Morien <roymorien@...> wrote:
      >
      > Why isn't there a sense of urgency in what I said? Adopting a new
      > development approach that is so RADically (sorry, I couldn't stop myself
      > with that ) from the traditional approach surely brings with it some
      > excitement and anticipation of success, and maybe even a little bit of fear
      > of failure, so this will instill a sense of urgency, I would suggest (and
      > hope).
      >
      >
      >
      > Timeboxing is not essentially about estimating and being accurate in
      > estimates. The mere fact that you have a timebox, and you have undertaken to
      > complete a certain set of tasks in that time, instills the sense of urgency.
      > As I said before, so what if you take on too much and don't complete it. In
      > a seriously trying team, that just means you were over-enthusiastic at the
      > start; not a bad thing, i would suggest.
      >
      >
      >
      > Anyway, let's ot be controversial about this. Good idea to go agile. I
      > applaude it (and so would everyone else who contributes to this forum). So
      > ... Go Man! Do it, don't just talk about it! Write code, not documentation!
      > Deliver value!
      >
      >
      >
      > Regards,
      >
      > Roy Morien
      >
      >
      >
      > To: scrumdevelopment@yahoogroups.com
      > From: myip11@...
      > Date: Thu, 8 Oct 2009 04:13:00 -0700
      > Subject: RE: [scrumdevelopment] Sprint planning using team capacity and
      > detailed tasks vs.story-level estimates
      >
      >
      >
      >
      >
      >
      >
      >
      >
      >
      > Roy,
      >
      > Some people work better when there is a sense of urgency when work are time
      > boxed. This may have nothing to do with " PROPHECY" or wanting to be correct
      > in estimating.
      >
      > Michael
      >
      >
      > --- On Thu, 10/8/09, Roy Morien <roymorien@...> wrote:
      >
      >
      > From: Roy Morien <roymorien@...>
      > Subject: RE: [scrumdevelopment] Sprint planning using team capacity and
      > detailed tasks vs.story-level estimates
      > To: scrumdevelopment@yahoogroups.com
      > Date: Thursday, October 8, 2009, 5:36 AM
      >
      >
      >
      >
      > Why do you, like so many others, place such first-up importance on
      > estimating? Frankly, my suggestion would be to concentrate on getting into
      > the swing of things with an iterative approach, having your reviews,
      > producing stuff that works, making the user happy by taking their change
      > requests seriously and dealing with them in a timely fashion, and settle
      > into this scheme of things.
      >
      > More ACTION, Less PROPHECY! It is more important to demonstrate the
      > fast-lane production of working software components than struggling with the
      > question of how long it might take, and how correct you are in that
      > estimate.
      >
      > If you take on too much in a sprint, then that'll be a lesson for you. If
      > you take on too little, then there is nothing that says you can't grab
      > another story to develop. You'll soon get the hang of it.
      >
      > Regards,
      > Roy Morien
      >
      >
      >
      >
      > To: scrumdevelopment@ yahoogroups. com
      > From: markpetronic@ gmail.com
      > Date: Fri, 2 Oct 2009 04:23:35 +0000
      > Subject: [scrumdevelopment] Sprint planning using team capacity and detailed
      > tasks vs.story-level estimates
      >
      >
      >
      >
      > I'm trying to introduce Scrum and Agile practices into my company which is
      > very waterfall based. I have done a lot of reading on Agile practices and
      > attended a certified SM training course recently. I have a team of 6 plus me
      > as SM. We are all trying to be productive and learn how to do this at the
      > same time. It's fun and challenging at the same time. My basic question
      > revolves around how accurately a team should try to estimate their time
      > during sprint planning? We started with 2 4-week sprints and decided we
      > needed to move to 2-week sprints so we can have more frequent opportunities
      > for feedback and adjustments. We just planned our first 2-week sprint this
      > week. In doing so, we started by pulling the top ranked stories and adding
      > tasks and tests. We tried to estimate each task so that each team member's
      > ideal hours for the sprint were accounted for using 6 hours/day as each
      > person's ideal hours. Historically, I know that is probably optimistic and
      > we can adjust as we see how this goes over time. Since we don't know what
      > our velocity is yet it's hard to judge what we can do at this point based on
      > story points. We estimated the stories by trying to use ideal days instead
      > of story points because we are all having trouble getting our minds around
      > story points. Should we really be concerned with trying to account for
      > everyones total capacity during detailed planning of tasks? Is this going
      > too far? Another area we had some trouble with was tasks where two or more
      > team members worked together. Should we define one task per person? Seems
      > like overkill and I think is coming from the MS Project past where you
      > assign resources to tasks and get a total man-hours that represents the
      > product of N resource times X hours for that task.
      >
      >
      > Here's a very specific question regarding this topic: Let's say we decide to
      > plan a spike to look into something like, "Do we need a OS abstraction layer
      > framework or not for our product and if so, how should it be designed?" We
      > time box it for 2 hours but 4 members of the team are going to participate.
      > That's 8 hours. Should I just specify a story that reflects 8 hours or
      > create a design spike story and assign four tasks (one for each person) and
      > reflect each will spend 2 hours?
      >
      >
      > Thanks in advance for your wisdom and insights...
      >
      >
      >
      >
      >
      >
      >
      >
      > Check out The Great Australian Pay Check Take a peek at other people's pay
      > and perks
      >
      >
      >
      >
      >
      >
      > _________________________________________________________________
      > Take a peek at other people's pay and perks Check out The Great Australian
      > Pay Check
      > http://clk.atdmt.com/NMN/go/157639755/direct/01/

      --
      Sent from my mobile device
    • Show all 19 messages in this topic