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

Re: [scrumdevelopment] crediting velocity for a story that didn't fit in one sprint

Expand Messages
  • Elizabeth V Woodward
    Dave, I had a similar question come up with a team just this last Friday, where...after some discussion...it became clear that a scrum master was thinking of
    Message 1 of 5 , Aug 24 5:25 PM
    • 0 Attachment

      Dave, I had a similar question come up with a team just this last Friday, where...after some discussion...it became clear that a scrum master was thinking of velocity in terms of the amount of work done within a specific sprint, rather than viewing it as the long term measure of the amount of work that the team could get done within a sprint. Looking at averages (ala Cohn's Agile Estimating & Planning Workshop) seems to work very well for teams...average of the last 8 or the average of the worst 3. You can look at your team's trends over time, but just looking at how much work is done in each specific sprint doesn't tell us much. So, I don't think there's really an "artificial" spike or "artificial" low...it is what it is. And, using the averaging method... we don't split up the work between the sprint started and sprint finished... or add overhead by re-estimating the work remaining. We claim all points when the story completes.

      That link is an interesting read... If the goal is to help the team to transition from having 500 things going at one time (and looking incredibly busy while not actually getting anything done) to actually taking a few things to "done, done, done, done" within a sprint, I would have to say that peer pressure seems to work pretty darn well and definitely better than someone grading a team on their completion of user stories. (yikes!) It's amazing how painful it is for a team to get to the end of a sprint and have nothing to demo to stakeholders... and no points to claim.

      -elizabeth

      Inactive hide details for "Dave Smith" <davewsmith@...>"Dave Smith" <davewsmith@...>


              "Dave Smith" <davewsmith@...>
              Sent by: scrumdevelopment@yahoogroups.com

              08/24/2008 02:41 PM

              Please respond to
              scrumdevelopment@yahoogroups.com


      To

      scrumdevelopment@yahoogroups.com

      cc


      Subject

      Re: [scrumdevelopment] crediting velocity for a story that didn't fit in one sprint


      On Sun, Aug 24, 2008 at 7:06 AM, Matt McClure <mlm@...> wrote:
          In the thread titled "Consequences",

          On Thu, Aug 21, 2008 at 8:44 AM, Hal Macomber <
          hal@...> wrote:
          > Don Gray's causal loop diagram
          > [
          http://www.donaldegray.com/tiki-view_blog_post.php?blogId=3&postId=75]
          > shows how that approach has the opportunity to perverse the behavior of an
          > individual performer.

          Thanks for the link. Don says there,

          "Mentally allowing that I haven't seen all the possible user stories
          in the world (and there /MIGHT/ be one story so large it couldn't be
          finished in a sprint, I continued ... 'If that doesn't work, pull the
          work into the sprint and burn down as much as possible. You don't get
          velocity points, but if the backlog is properly ordered you'll have
          work done for the start of the next sprint.'"

          Assuming that a big story were completed in the next sprint, how
          /would/ you credit velocity for it?

          I can rationalize using the full original estimate when it is
          completed on the grounds that it provides positive feedback to the
          team and reflects the total cost paid (over the two sprints). But the
          velocity would then show an artificial spike in the sprint when the
          work was completed. Alternatively, I can rationalize using some new
          reduced estimate on the grounds that this is the cost paid in the
          sprint when the work was completed.

      I approach this by imaging some significant event that causes the
      next sprint backlog to be planned with entirely new stories. In that
      case--and in all cases, really--I want to have a good handle on the
      capacity of the team to complete work (i.e., their velocity). It doesn't
      help to have a velocity that's artificially low or high because we
      played games with partially completed work in prior sprints.

      I've never met a bigger-than-a-sprint story that couldn't be split
      split into smaller, estimatable pieces. If I did, I might wonder if the
      sprints where too short.
          Do you reestimate the cost of stories that were started and not completed?

      For planning purposes, everything with a previous estimate gets the
      opportunity for a new estimate, with work-to-date counting for naught.

      Dave


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