title: Planning and coping with deadlines in Scrum
body: <p>From <a href="http://en.wikipedia.org/wiki/Scrum_(development)#Characteristics" rel="nofollow noreferrer">wikipedia</a>:</p>
  
  <blockquote>
    <p>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. <em>The team then
    determines how much of this they can
    commit to complete during the next
    sprint</em>. During a sprint, no one is
    allowed to change the sprint backlog,
    which means that <em>the requirements are
    frozen for that sprint</em>. After a sprint
    is completed, the team demonstrates
    the use of the software.</p>
  </blockquote>
  
  <p>I was reading this and two questions immediately popped into my head:</p>
  
  <p>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!</p>
  
  <p>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?</p>
  
  <p>The wiki article goes on to talk about Sprint planning, where things are broken down into much smaller tasks for estimation (&lt;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.</p>
  
  <p>BTW:</p>
  
  <blockquote>
    <p>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.</p>
  </blockquote>