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

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

Expand Messages
  • Adam Sroka
    Oct 8, 2009
    • 0 Attachment
      Radical means "Favouring fundamental change, or change at the root
      cause of a matter."

      Timeboxing isn't about creating a sense of urgency. Timeboxing is
      about having a shared expectation and commitment of when we will
      perform a certain activity. In Scrum it is about when we will engage
      in the various group ceremonies. Working from 9 to 5 is an example of
      a timebox with a very similar purpose.

      Having stuff done at a particular time means that we can get together
      and review that progress. Good teams achieve some measure of "done" in
      much less time than an iteration. For example, if you are doing TDD
      and Continuous Integration well there is a measure of "done" that
      occurs many times a day.

      On Thu, Oct 8, 2009 at 9:04 PM, Michael Yip <myip11@...> wrote:
      >
      >
      >
      > Roy,
      >
      > Being radical is taking things for granted and taking things for granted as mentioned or proposed. Having a sense of urgency is NOT a fear of failure and definately not being traiditonal. Extremenly surprised and by your claim. Sorry
      >
      > 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, 11:08 PM
      >
      >
      > 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@yahoo. com
      > 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@hotmail. com> wrote:
      >
      > From: Roy Morien <roymorien@hotmail. com>
      > 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
      >
      > ________________________________
      > Check out The Great Australian Pay Check Take a peek at other people's pay and perks
      >
      >
    • Show all 19 messages in this topic