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

Re: [scrumdevelopment] Re: Sprint Planning and Hourly Estimates

Expand Messages
  • Steve Ropa
    Yes, I thought you were making the argument that the 11 hour days were sustainable pace for that team.. Even so, the hours estimates are not precise anyway.
    Message 1 of 24 , Apr 12 7:27 AM
      Yes, I thought you were making the argument that the 11 hour days were "sustainable pace" for that team..  Even so, the hours estimates are not precise anyway.  Tracking the number of hours worked is a double edged sword, in my opinion.  Just as tracking the hours can show that they team has been working too many hours, it can also be used to browbeat the folks who don't "put in the extra time?"  After all, you don't want just the minimum amount of flair, you want to show some spirit and have extra pieces.
       
      Management needs to learn what sustainable pace is, regardless of the number of hours.  The best way to do that is to let the team sign up for what they believe they can accomplish comfortably, without heroics.  Management needs to just make sure they are supporting the team's decision, and not trying to influence it.  And never ever ever commit to the customer any more than the team has committed to them.  Sadly, this very simple idea seems to keep disappearing in project management circles.
       
      Sent: Saturday, April 10, 2010 8:49 PM
      Subject: Re: [scrumdevelopment] Re: Sprint Planning and Hourly Estimates

       

      Hi Steve,
       
      It matters a lot when a team works for 11 hours or more. May be, I was not clear in my initial response. When some enthusiasts work for 11 hours and management gets an impression that one day is equivalent to 11 hours. Soon, Management starts expecting team to work at that velocity only. Now, if team wants to come back to 7 hours, its hard and they might be percieved as non-performer.
       
      Even team looses morale soon and starts coming late to office (as one needs some decent sleep) and a negative cycle starts. Hence, my humble advice is to estimate in hours to remove any ambguity and than if team/management chooses to work any number of hours, is fine. But everyone involved must realize that we worked these many hours to achieve schedule and there is no 1:1 mapping with # of working hours in days.
       
      In my view, estimating in hours is in benefits of team as most of the management folks track schedule and does not care how many hours one puts in per day to achieve that schedule. I have come across many cases where people left due to burn-out but they do not realize that they themselves had put them in this situation some time back by opting to work late voluntarily and nobody tracked number of hours they worked per day. Management see a particular velocity and starts committing to customers keeping that in mind and pressure starts building. In long term, nobody gains.
       
      - Hari

      On Fri, Apr 9, 2010 at 7:31 PM, Steve Ropa <theropas@...> wrote:
       

      Hi Hari,
       
      If that pace really is the sustainable pace of your teams, does it matter that one day is 11 hours?  I certainly wouldn't recommend that, but if it consistently turns out that way, what are you gaining by knowing how many hours something might take, or how many days that would be if someone else were working on it?  Like many others, I have become increasingly skeptical as to the value that task estimation brings.  Intellectually I understand the value of breaking stories into tasks as a design activity, but in practice I've found that it tends to cause more angst than it serves to help design.  So I would personally suggest trying without tasks, then if you really want to break things down into tasks, make that a design activity and don't bother estimating them in hours or days.
       
      regards,
      Steve

      Sent: Friday, April 09, 2010 1:26 AM
      Subject: Re: [scrumdevelopment] Re: Sprint Planning and Hourly Estimates

       

      I have another reason to estimate in hours. I have found some cases where management (or PO) means 1 day is equivalent to 10 hours however development team meant it 6 hours. I have also seen cases other way around where developer feels he can work it till late night and complete it by 11 PM however management (or PO) thinks that the delivery time is End of Day means 6 PM or so.
       
      Another reason is that most of bachelors (especially in India) usually work till late night and if I ask them how long it took to do that story, they tell 3 days and if I ask them how many hours than they tell, probably, 33 hours. Now, when I estimate it next time, I  would caution them to do estimates in hours so that they do not set an high expectation from everyone around them. I have found that neither management nor developer minds working late for their own reasons hence I want everyone to realize that although it took 3 days but in other terms, it was actually 4 days or more.
      To avoid such interpretations of # of working hours in a day, I inclined to tell them to estimate in hours.
       
      One amy also read the thread "estimating in hours" to understand it more.
       
      - Hari
      On Fri, Apr 9, 2010 at 10:28 AM, Adam Sroka <adam.sroka@gmail. com> wrote:
       

      On Thu, Apr 8, 2010 at 4:41 PM, John Goodsen <jgoodsen@radsoft. com> wrote:
      >
      >
      >
      > All sounds good.  What if you spec out stories just prior to development? Do you still need iteration planning?
      >

      Insofar as those stories you are just about to develop constitute an
      "iteration" yes. It is precisely the same thing. You can iterate on a
      time box or an increment of scope (e.g. a story) It doesn't
      fundamentally change the nature of planning.




      --
      Regards,
      Hariprakash Agrawal (Hari),
      An Agile Coach (XP, Scrum), Certified Scrum Master, Trained Six Sigma Black Belt, CMMi Consultant, ISO 9001:2000 Lead Auditor, MTech (Reliability & Quality Engg) from IIT-KGP
      http://opcord. com - OpCord provides trainings/consultin g on many frameworks/processe s and testing services for organizations




      --
      Regards,
      Hariprakash Agrawal (Hari),
      An Agile Coach (XP, Scrum), Certified Scrum Master, Trained Six Sigma Black Belt, CMMi Consultant, ISO 9001:2000 Lead Auditor, MTech (Reliability & Quality Engg) from IIT-KGP
      http://opcord. com - OpCord provides trainings/consultin g on many frameworks/processe s and testing services for organizations

    Your message has been successfully submitted and would be delivered to recipients shortly.