What to do if the sprint duration is shorter than expected?
- 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
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
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
- 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
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.
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