title: Help me understand how QA works in Scrum
body: <p>Apparently we use the Scrum development methodology. Here's generally how it goes: </p>
  
  <p>Developers thrash around trying to accomplish their tasks. Generally the tasks take most of the sprint to complete. QA pesters Dev to release something they can test, Dev finally throws some buggy code out to QA a day or two before the sprint ends and spends the rest of the time fixing bugs that QA is finding. QA can never complete the tasks on time, sprints are rarely releasable on time, and Dev and QA have a miserable few days at the end of the sprint.</p>
  
  <p>How is scrum supposed to work when releasable Dev tasks take up most of the sprint? </p>
  
  <p>Thank you everyone for your part in the discussion. As it's a pretty open-ended question, it doesn't seem like there is one "answer" - there are many good suggestions below. I'll attempt to summarize some of my "take home" points and make some clarifications.</p>
  
  <p>(BTW - Is this the best place to put this or should I have put it in an 'answer'?)</p>
  
  <p>Points to ponder / act on:</p>
  
  <ul>
  <li>Need to ensure that developer tasks are as small (granular) as possible.</li>
  <li>Sprint length should be appropriately based on average task length (e.g. sprint with 1 week tasks should be at least 4 weeks long)</li>
  <li>Team (including QA) needs to work on becoming more accurate at estimating.</li>
  <li>Consider doing a separate QA sprint in parallel but off-set if that works best for the team</li>
  <li>Unit testing!</li>
  </ul>