* Successful demo of planned features
  * Code can be delivered inactive
    * ok for multi-sprint projects
  * bad for stuff that was externally committed
* Interruptive priorities
  * Commited work sometimes pushed out for emergency bugs/features
  * Plan for less than 100% capacity in a given sprint
  * Make sure that committed work drops off if interrupts happen
* Sizing versus Commitment
  * Separate the process of determining level of effort from stating what must get done
  * Make sure you understand how much you can do sustainably before committing
* Measure "Project Success" or "QA Process Success"?
  * The whole project depends on:
    - Product definition
    - Development skill
    - Testing skill
    - Production monitoring
  * QA Process is a subset of Testing Skill
    - Test planning
    - Test development
    - Test execution
  * Everything should be examined in the retrospective and improved each iteration
  * Think about success for a feature versus success for the larger system
  * Make sure you measure how good your measurements are (do you get better at estimation and commitment?)
* Who measures?
  * Scrum masters have the time, focus and independence
  * Need to build trust that valuable things are being measured accurately and independently