Re: [scrumdevelopment] Digest Number 777
>I simply do not view our cycle as a 90 day sprint. The pre-planningYou may choose not to view it as a 90 day sprint, but if it quacks and
>process is outside the sprint. The goal is to get a reasonable set of
>high-priority items into the product backlog, so the teams can get a
>running start at the beginning of the sprint.
To me, one of the benefits of Scrum is that it ensures that the team is
always focused on items that the customer has determined that to be of a
high priority. Furthermore, the customer gets constant, timely feedback on
the activities of the team. If the pre-planning is happening outside of a
Sprint, then where are your controls to ensure that they aren't wasting
time working on low priority items or going off in the wrong direction
From my point of view, activities outside of a Sprint are "chaos". I want
to pull as much of the team's work inside my Sprints so that they are
properly controlled. It's NOT A GOOD THING to have your analysis happening
outside of a Sprint.
>Scrum does not state how long it takes, or by what process, a featureActually, it does. Anyone can add anything to the PB at any time. It
>gets inserted into the backlog.
takes about as long as you need to ask for something.
What I think you're actually talking about is the prioritization process
and the inclusion of a PB item in a Sprint Backlog. Once again, these are
very well defined. The Product Owner has sole responsibility for assigning
priorities. Determination of the Sprint Backlog is supposed to happen in a
4 hour Sprint Review meeting. Furthermore, there isn't supposed to me more
than 1/2 hour preparation done for the Sprint Review meeting.
Back to the prioritization. Practically speaking, most product owners need
some estimate of the cost or time required to complete a PB item in order
to set the priority. My experience is that a BOOM estimate is good enough
for this purpose. Most Product Owners could care less if a PB was going to
take 37.5 hours to complete or 39 hours; "something like 5 days" is good
enough for setting priorities.
As to the post development activites: It sounds to me more like you are
doing Release activities than plain testing. Do you really do 30 days of
testing for each 30 days of development (I know, times 12 teams)? Do you
really deploy to dozens of external customers each month? Are you
deployment activities really an empirical process, or is it pretty much
defined by now?
Regardless, what would happen if you shrunk the amount of programming being
done each month down by 1/3, allowed for all of the analysis to happen in
the same Sprint as the development and then tested in the same Sprint?
Now, that would be Scrum.
Anyways, at this point we've clearly gone past discussion and moved into
holy war. Do what you want, call it what you want. Have lots of success
Lawyers' Professional Indemnity Company