From wikipedia:
During each “sprint”, typically a two
to four week period (with the length
being decided by the team), the team
creates a potentially shippable
product increment (for example,
working and tested software). The set
of features that go into a sprint come
from the product “backlog,” which is a
prioritized set of high level
requirements of work to be done. Which
backlog items go into the sprint is
determined during the sprint planning
meeting. During this meeting, the
Product Owner informs the team of the
items in the product backlog that he
or she wants completed. The team then
determines how much of this they can
commit to complete during the next
sprint. During a sprint, no one is
allowed to change the sprint backlog,
which means that the requirements are
frozen for that sprint. After a sprint
is completed, the team demonstrates
the use of the software.
I was reading this and two questions immediately popped into my head:
1) If a sprint is only a couple of weeks long, decided in a single meeting, how can you accurately plan what can be achieved? High-level tasks can’t be estimated accurately in my experience, and can easily double what seems reasonable. As a developer, I hate being pushed into committing what I can deliver in the next month based on a set of customer requirements. This goes against everything I know about generating reliable estimates rather than having to roughly estimate and then double it!
2) Since the requirements are supposed to be locked and a deliverable product be available at the end, what happens when something does take twice as long? What if this feature is only 1/2 done at the end of the sprint?
The wiki article goes on to talk about Sprint planning, where things are broken down into much smaller tasks for estimation (<1 day) but this is after the Sprint features are already planned and the release agreed, isn’t it? Kind of like a salesman promising something without consulting the developers.
BTW:
Although the word is not an acronym,
some companies implementing the
process have been known to spell it
with capital letters as SCRUM. This
may be due to one of Ken Schwaber’s
early papers, which capitalized SCRUM
in the title.
You are supposed to use the velocity to plan the next sprint. The velocity neatly handles the fact that your estimates are wrong, but they are consistently wrong. Also note that stories are supposed to be short, I’d say maximum 2-3 days. Stories that are bigger than that should be broken down into smaller stories.
If one story is not completed as planned, then your velocity goes down and you wont be able to take on as much work in the next iteration.