구현 가능성에 대한 검토를 언제 해야하는 것인가?
희망이 프로젝트를 죽이기 전에 희망을 파괴할 수 있다
애자일은 우리가 얼마나 망했는지를 최대한 빨리 아는 것이다

스토리를 최대한 완료시키려는 것이 중요하지 작업 속도를 높이려는 것은 아니다. 진행 상황을 보다 구체적이고 측정하기 좋게 만들려는 것이며, 신뢰할 수 있는 데이터를 얻기 위한 것이다.
완료의 기준은 인수 테스트 통과이다. 완료 티켓으로 넘기기 전에 테스트 통과하는 것을 보고 넘기도록 한다.
TDD 작성할때에는 각 스토리 별로 작성을 해야 한다. 왜냐하면 스토리는 독립적이고 언제든 개별로 배포가 가능한 수준이기 때문에 테스트에도 의존성이 존재하면 안된다.
정상에서 벗어난 경로도 함께 생각해야 한다. 시스템을 망가뜨리는 궁리를 함께 해야 한다
여기서 QA의 역할은 단순히 테스트만 하는 사람이 아니라 프로젝트 초기에 명세를 작성하는 사람으로 바뀐다.
문제를 예방할 수 있도록 이끌어야 한다.

속도는 측정하는 것이지 목표하는 것이 아니다. 측정하려는 대상에 압력을 가하지 말라
스프린트에서 목표하는 것은 데이터이다. 스프린트에서 실패한 것은 데이터를 얻지 못했을때이지 스토리를 전부 완료하지 않았을때가 아니다.