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

Re: What to do if the sprint duration is shorter than expected?

Expand Messages
  • Rob Park
    I haven t read all of this, but the 7 or 10 days jumped off the page at me. To avoid your problem in the future, try to get all stories to 2d or less. For
    Message 1 of 38 , Nov 1, 2007
      I haven't read all of this, but the "7 or 10 days" jumped off the
      page at me. To avoid your problem in the future, try to get all
      stories to 2d or less.

      For us, we're currently at ~ 11 points per week and our normal max
      story size is 3. If something is a 5, we'll most often split it and
      only occasionally go for it (against our own better judgment).

      .rob.

      > (responding to Michael)
      > The two stories can take 7 or 10 days, because they are a little
      > complex (it's about async notifications), so the PO can talk with
      the
      > client in order to wait these days before to release the product to
      > QA India and then release it to Production. He thinks that the
      client
      > can wait, but the dilema is in our Team due to the SCRUM rules. I
      > remember read some posts/articles about that the SCRUM rules are
      > suggestion (SCRUM is a Framework) so these rules can be "adapted"
      by
      > the Team, SM and PO, so I'm not sure if we have to "adapt" the
      rules
      > in this case without became this "adaption" in a rule (the Sprint
      > duration can be flexible). About the Impediments and Velocity, as I
      > said before, we are starting with Scrum and we are improvements our
      > velocity estimation and the Team's commitment, so I think that the
      > problem isn't in this part.
      >
    • Rob Park
      That is a tough spot where your clients don t want or can t deploy as frequently as you d like. It does sound like you re doing what you can to get stuff in
      Message 38 of 38 , Nov 28, 2007
        That is a tough spot where your clients don't want or can't deploy as
        frequently as you'd like. It does sound like you're doing what you
        can to get stuff in their hands. And with government, I can only
        imagine trying to get them to change. Yikes.

        That said, and with Roy's comments as well, my experience has been
        that people worry a lot more about this than is truly worth it. If
        we're only talking 2 weeks of work, how much training do you really
        need? Expect to do? For each of these releases is there really
        anything that's disruptive? Do you really need to train every 2
        weeks?

        All I'm trying to say is maybe, maybe not. In your case, it sounds
        like you've tried or are trying to deploy as often as possible, which
        is the right thing to do IMO. But a lot of folks out there will be
        much more dismissive and say it's just too disruptive without thinking
        about it. That's not good, again IMO.

        .rob.

        On 11/27/07, Nicholas Cancelliere <nickaustin74@...> wrote:
        >
        > Where I am right now. The team meets with the PO every 2 weeks to
        > review the priority features and work on them. At the end of the two
        > weeks the features are placed on a demo server and demonstrated to the
        > PO (and the customers get to review them as well). Feedback is then
        > incorporated into future sprints as necessary.
        >
        > The client isn't always going to want to have new features in
        > production every 2 weeks. We deal with state governments, and they
        > like to train their employees on the new features. Introducing new
        > features into production every 2 weeks puts a huge burden on their
        > organization. (And we try to make it a practice to not burden
        > customers!) So instead we release to production after the features
        > are all done and the customer feels it enough critical mass to warrant
        > training. (Generally it's every quarter 3-4 months).
        >
        > We do have working product increments every 2 weeks though going to
        > our demo server ... so it's still Scrum. There's nothing in Scrum
        > that says you have to be putting code onto production every 2 weeks.
        >
        > ---
        > Nicholas Cancelliere
        > Austin, TX
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.