RE: Completeness definition
>Sure, the work can be chunked into 30I think, just like the "pigs and chickens" thing (which is only about who
>day sprints, and we can build the application with localized testing for
>the module we just completed, but it can't go to production until
gets to speak in a daily scrum), people lose track of what the Scrum "rule"
about "potentially implementable" features is all about.
There isn't any rule that your entire product has to be deployable at the
end of every Sprint. IMHO, the rule about making each Sprint Backlog item
a "potentially implementable" feature has two purposes:
1. To keep the team focused on "functionality". Creating an artifact, or
investigating an approach is not a valid SB item. You need something that
you can demo to the user at the end and show forward movement on
2. To keep the team focused on finishing. Starting something doesn't
count. Finishing it does. Size things so that they can be completed, even
if this means that the incremental gain in functionality is so small as to
be useless to the end user as a practical matter.
I don't see any conflict here with scheduling releases to occur some
quantity of Sprints in the future, nor do I see any conflict with dealing
with necessary pre-release activities. I don't think you need to be filled
with angst because some feature that you've developed can't be "released"
until the whole system has been stress tested for 2 weeks in a lab. The
rules do make you think about what you are doing, and potentially knock out
a whole pantload of activities as valid SB items. For instance:
3. Unit Testing
4. User Training
6. Bug fixing (as an open-ended, general activity)
Wouldn't ordinarily qualify. Instead if a feature needs those items
completed in order to be considered "potentially implementable", then they
should be included in the SB item for the development of that feature.
Even here, though, you may need to make exceptions. For instance, you may
have a separate documentation department, who work on their own schedule
and need to see a final version of the product before they will update
documention. The spirit of the thing is the most important: Only take on
as much stuff as you can finish, and be clear about what "finishing" means.
Lawyers' Professional Indemnity Company