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

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

Expand Messages
  • Deusdit Correa Cornejo
    Hi all, I have a dilema, this is our second sprint, and after the Sprint Planning, the team decided that 2 Stories cannot fit in the Sprint (due to their
    Message 1 of 38 , Oct 29, 2007
    • 0 Attachment
      Hi all,

      I have a dilema, this is our second sprint, and after the Sprint
      Planning, the team decided that 2 Stories cannot fit in the Sprint
      (due to their complexity and so, theirs longer duration)... but after
      our PO talked with the client they said that these 2 stories are also
      required (in short all the stories are required).

      So we have some options:

      1. Take off some of the already estimated stories
      2. Reduce the Scope of the stories in order to include the other 2
      Stories.
      3. Make the Sprint longer to include these 2 stories

      The first option is not supportable, because as they said, all the
      stories are required. With the first and second and third option, we
      will give to the client less than they expect. The third sounds more
      logical, but I'm affraid that if we expand the Sprint duration, this
      becomes in a bad habit (the exception becomes the rule) and the idea
      of to have a constant and defined time for release the product can be
      faded.

      Besides, the Bussines people wants we develop all these stories
      because that is one of our most important client.

      I'd like to get some advices from you guys, maybe you were in the
      same trouble.

      Regards,

      Deus.
    • 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
      • 0 Attachment
        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.