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

Re: [scrumdevelopment] Small team w multiple projects - tales from the voyage

Expand Messages
  • Paul Hodgetts
    ... I have an exercise that I always like doing with teams to get them to define and agree to what done means. I put up 3 big Post-its on the wall, and label
    Message 1 of 4 , Apr 28, 2006
    • 0 Attachment
      Bill Wake wrote:

      > The other place I find people get jammed up is understanding
      > just how done "done" is intended to be (what it means to be
      > "shippable" at the end of each sprint). People tend to forget
      > testing, documentation, packaging, etc. and then find that
      > ignoring these things didn't make them go away:) - and that
      > they still have to happen before deployment.

      I have an exercise that I always like doing with teams to get
      them to define and agree to what "done" means.

      I put up 3 big Post-its on the wall, and label them "Task,"
      "Story" and "Sprint." I start at the Task one and ask them
      "If I said I was 'done' with a task, what would you expect
      that I would have done?" Same for story. We then discuss
      all the things that we should be doing in order to be really
      done with these things. The discussion that results is
      usually really interesting, and I almost always find that the
      team members have different views and expectations of done
      in their current process.

      For example, for a task we have things like code written and
      compiles, database scripts updated, unit tests pass, things
      are checked in and the team's build doesn't break, etc. For
      a story we have things like acceptance tests pass, the Product
      Owner has taken a look, help files updated, etc.

      After a bit, I then ask "If I told you we had to roll into
      production at the end of this next sprint, what else would we
      need?" I usually get some horrified looks, but we add more
      things to the list. This is where we get some things for the
      Sprint chart, such as performance tests, release notes, etc.
      that they may feel they would do once for the sprint.

      Sometimes, they feel they can not get everything done for a
      production release in a sprint, even if they use a longer
      sprint like 30 days. In that case, we may make a 4th chart
      for "Release" and those things would become items for that
      last sprint before a release.

      After we've discussed and agreed to these lists, I get them
      to step back and consider that we need to make sure we account
      for all this work in our sprint, otherwise we're just building
      up "debt" that we have to pay off eventually, usually with
      some pain involved. The room often gets pretty quiet at this
      point as they realize what it all means.

      I also will revisit this list after a couple of sprints and
      use it as a centerpiece for discussing how we can improve our
      process. We discuss items we missed and especially how we
      can get the items to move further and further to the left
      (towards Task).

      This exercise can take somewhere around 30 minutes or longer
      to go through, but I highly recommend that every team does
      this before they try to do any estimating or plan a sprint.

      Paul Hodgetts -- CEO, Coach, Trainer, Consultant
      Agile Logic -- www.agilelogic.com
      Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP
      Complete solutions for adopting agile processes, Scrum and XP.
    Your message has been successfully submitted and would be delivered to recipients shortly.