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

37031Re: [scrumdevelopment] Don’t Split A Story Into Tasks

Expand Messages
  • Mamun
    Mar 12, 2009
      Probaly we can talk months on the benefits or limitations among various estimation techniques. Actually there is no "ultimate" approach, each has its own pros and cons. By born Scrum is an empty box, providing the boundary lines only, we can put whatever we want into the box considering our own-context, BUT always by keeing the values intact.
      To share you my experiences, in my team, we follow both Story points (for PBLs) and hours (SBLs) estimation and it works fine for us. But to avoid any lengthy plannig session (which we know don't add value after a point), we don't find tasks and then put hours (1 hr, 2 hr etc.) - we do it in the reverse way. We agreed we will only have half-day (3 hrs) and full-day (6 hrs) tasks. So team quickly find tasks that fits the 3-hr or 6-hr buckets.
      The best point I see for hour estimation (for tasks) is: it really helps my team to visualize the sprint targets as team runs on 24 HOUR sprint cycle and  Hr to Hr comparison is straight. I have also seen the hour based burndown chart always tells the truth about sprint health.
      ~M N Mamun

      --- On Thu, 3/12/09, Adam Sroka <adam.sroka@...> wrote:
      From: Adam Sroka <adam.sroka@...>
      Subject: Re: [scrumdevelopment] Don’t Split A Story Into Tasks
      To: scrumdevelopment@yahoogroups.com
      Date: Thursday, March 12, 2009, 10:40 AM

      On Wed, Mar 11, 2009 at 9:22 PM, Sarath Kummamuru <kcsarath@gmail. com> wrote:
      > Hi Adam,
      >     I have found a couple of sure benefits (IMO) of estimating in hours.
      >     1. Estimating in hours helps the team identify tasks that are very big
      > and allows them to use guidelines like break down the tasks into small units
      > say 2 - 8 hours. This ensures that it avoids behavior where a team member
      > just says " I will do this task, its going to take about 18 hours (3 days
      > say) and then the task becomes a black box for the other team members. Using
      > a guideline saying that we estimate them in hours of 2 - 8 hours ensures
      > that the size of the tasks are small.
      >        The goal of estimating in hours is not to micro manage and say "Hey
      > buddy you said you are going to get done in 2 hours why is it not done?".
      > But more for the team member to come back in the daily scrum and say "Hey
      > guys i thought this task would be about 2 hours, but it took longer because
      > of these reasons, etc".

      Maybe it is because we sit together, and we pair program, but the idea
      that someone would go off and work on something for three days and it
      would be a "black box" is completely foreign to me. If that were
      possible, how would estimating smaller help? Smaller black boxes
      doesn't sound like an improvement.

      >        One practice I strongly advocate is that people should be free to
      > pick up any task they want from the board. So if lets say i estimated a
      > middle tier task for about 4 hours (since i am a typical middle tier guy) if
      > some one else wants to pick it up during the course of the sprint, they can
      > actually get to me, discuss and say "Hey sarath i would like to do this
      > task, you estimated it at 4 hours, can you guide me/Pair with me on getting
      > the task done".

      Definitely. We want anyone to do any task they feel they are able to.
      Ownership is counterproductive in an Agile environment.

      >    2. Estimating hours for tasks during the sprint planning session (at the
      > start of a sprint) ensures that the whole team has a perspective of the
      > distance to travel and keep an eye on how they are going with the Sprint
      > Burndown chart. I have a huge loyalty to the Sprint Burndown and tracking
      > the distance to the end of the sprint in terms of the initial estimated
      > number of hours.

      I suppose I am presuming that there is some discussion during the
      planning session where we all agree what things we are going to get
      done this iteration. In the course of that discussion we should
      develop a shared understanding of what needs to be done. I'm just not
      sure how the concept of ideal-hours helps in that process.

      >        There are a few other suggestions that have been discussed in this
      > group like total number of test cases that have succeeded for each task,
      > etc. But i find task estimate in hours works best.

      I'm not sure that any sort of number really helps. I have mentioned
      that I like to list acceptance criteria, and that those criteria are
      the basis of acceptance tests. However, I don't count them. Once
      again, I am only interested in a general consensus about the effort
      involved and whether that effort fits in the iteration or not.

      >        the challenge though is for the team to realize that these are not
      > commitments but estimates and should drive discussion and strategies to get
      > the tasks done rather than be used as a micro management tool over each team
      > member.

      Agreed. But, to take that a step further, if we aren't going to use
      hours to micro-manage what are we going to use them for? Is there
      anything that we need to do that we can't do without them? And if so
      why bother?

    • Show all 89 messages in this topic