Skip to main content

Home/ Groups/ Agilesparks
Yuval Yeret

Agile Release Planning - 0 views

  •  
    including reference to critical chain
Yuval Yeret

Story points - Wikipedia, the free encyclopedia - 0 views

  • What use are they, especially when the question being asked is more often "how long will this take" vs. "how big is it?"
  • Is it that you want to know how long will what you asked for take, or when you will have what you want? (Or, in the case of a fixed date, the question becomes what are you most likely to get by that date?)
  • developers' unpadded/unbuffered estimates are statistically inaccurate (on average they are low) for requirements which (a) are not fully specified up front and (b) are mutable
  • ...10 more annotations...
  • time spent on estimation does not linearly result in greater accuracy (and in fact there is some evidence to state that the more time spent on estimates the worse they get after their "accuracy" peaks)
  • They are cheaper to arrive at
  • Why not Time-based Estimates for Release Schedule Planning

    While it is possible to continue to strive to use a time-based estimate of a project's scope to plan a schedule, there are several downsides to this approach when compared to using the points-based method. If you accept that requirements are rarely if ever fully fleshed out up front (and that the value of doing so is especially low for subjectively-determined goals such as visual design and usability), you can then propose that this detriment can be mitigated through proper schedule buffering. The assumption of buffering a schedule is that we know there are some unknowns we'll run into and we want to plan for it by adding time to the time-based estimated schedule. However, doing this will still suffer from the following disadvantages over using a points-based estimation technique (plus appropriate schedule and/or feature buffering) to plan the schedule:

  • A focus on time-based estimates will entail much more analysis and planning time as compared to points-based estimation.
  • A focus on time-based estimates forces the developers too low in their thinking of the projects too soon.
  • A focus on time-based estimates puts developers at the mercy of the question that management then feels compelled to ask, "why is your estimation accuracy so low?"
  • Time-based estimates necessarily depend on the resources brought to bear on a particular requirement or task. Knowing far ahead who will work on a requirement or task, what environmental factors will be in effect at that time, and even what new/changed information will be available to those resources at the time of execution is rarely possible.
  • Therefore, a time-based estimate's accuracy (however good or bad it is at the start) has a tendency to deteriorate over time. Using points combined with a team's velocity helps to smooth out these uncertainties and allow us to plan and track the schedule with a greater fidelity with a lower cost.
  • Find the simplest stories out of your backlog and start comparing other stories to them. Use "bucketing" (see below) as you begin to estimate in order to group similarly-sized stories. To start, do not assign point values to anything - just group your stories in similar buckets. Your bucket sizes should be relative to the other ones by a factor of 2, meaning that stories in bucket B are 2x the size of stories in bucket A, and the ones in bucket C are 2x the size of those in bucket B, etc. Once you are done, you can begin to assign 1, 2, 4, 8 etc. points to the stories in the relevant buckets.
  • Try to make sure your average story size (not 1-point story size!) is something that can be completed in the range of 5-8 (?)
1 - 20 of 821 Next › Last »
Showing 20 items per page