Re: What to do if the sprint duration is shorter than expected?
- 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).
> (responding to Michael)the
> 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
> client in order to wait these days before to release the product toclient
> QA India and then release it to Production. He thinks that the
> can wait, but the dilema is in our Team due to the SCRUM rules. Iby
> remember read some posts/articles about that the SCRUM rules are
> suggestion (SCRUM is a Framework) so these rules can be "adapted"
> the Team, SM and PO, so I'm not sure if we have to "adapt" therules
> 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.
- 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