ブログ

• チームに決定権限が与えられている
• チームは、自己組織化されていて、目標を設定して達成することを管理（者）任せにしない
• チームは成果物の提供に対してコミットし、責任を持つ。そしてチームがゴールに到達するために、あらゆるタスクに協力する
• チームはプロダクトオーナーが誰であるかを知っている
• それぞれのスプリント/イテレーションには明確なゴールが設定されている
• テスターを含む全てのチームメンバーは、要件を抽出するワークショップに参加する
• 要求事項の文書は十分にそろっている。そしてフィーチャーを実装できるレベルまで協力して詳細化する
• テストケースが要求事項やユーザーストーリーごとに事前に用意されている
• ビジネス上の価値によって優先順位付けされたプロダクトバックログやフィーチャーリストがある
• プロダクトバックログに、チームによって作成された見積りが載っている
• チームは自分たちのベロシティを知っている
• ベロシティは各スプリント/イテレーションにどれだけのストーリーを含められるかの指標に使われる
• スプリント/イテレーションは４週間またはそれ以下に区切られている
• スプリントの予算はどれだけのプロダクトバックログ、フィーチャーをそのスプリント/イテレーションに含めることができるかを決定するために計算される
• スプリント/イテレーションは、チームで合意している終了日に終了する
• スプリントバックログ内の全てのタスクは１日以下のタスクに細分化される
• 要求事項は、ユーザーストーリーとして記述されており、カードに書かれている
• チームはポイントを使って見積る。そのポイントはプロダクトバックログ/フィーチャーリスト内の各項目の相対的なサイズを示している
• チームは、日々の進捗をトラッキングするためにバーンダウンチャートを利用する
• ソフトウェアは各スプリント/イテレーションごとにテストされており動作する
• チームは、スプリント/イテレーションの間、（周りから）混乱させられない
• 変化はスプリント/イテレーションのあいだ、ずっと統合される
• 自動化されたユニットテストが適切に実装されている
• 自動ビルドと自動リグレッションテストがある
• 予想よりうまくいった場合に、スプリント/イテレーションに含める追加タスクを決めている
• プロダクトオーナーは、各スプリントに積極的に関わる
• 全てのコードの変更は元に戻すことができ、またいつでもリリース可能である
• テストはライフサイクルに統合されており、最初のフィーチャーのリリース時からテストをしている
• 進捗を妨げる障害は、ホワイトボードに記録されて、ただちに解決する
• 誰かが終わった！といったら、それは出荷可能（リリース可能）ということだ
• チームは日々の進捗や問題を、分かりやすく見える化するためにホワイトボードを利用する
• スプリント/イテレーションのゴールはホワイトボード上にはっきり書いてある
• すべてのユーザーストーリーとタスクはそのスプリント/イテレーションの期間中はホワイトボード上に表示されている
• たとえスクラムマスターが不在でもデイリースクラムは毎日同じ時間に実施しているか？
• デイリースクラムは標準の３つのスクラムの質問（昨日何やった？今日なにやる？困っていることは？）に答えるようになっていて15分以内に終了しているか
• スプリント/イテレーションの終了後に、製品のデモとスプリントレビューを実施している
• テスターを含む全チームメンバーが、スプリント/イテレーションレビューに出席している
• スプリント/イテレーションレビューにステークホルダー（顧客）が出席している
• 各スプリント/イテレーションの終了後にふりかえりを実施している
• 各スプリントのふりかえりでキーメトリクスのレビューと捕捉をしている
• テスターを含む全チームメンバーが、スプリントのふりかえり会に出席している
• スプリントのふりかえりで出たアクションが、次のスプリント/イテレーションで、前向きな影響を持っているか

原文は以下の通りです。

• The team is empowered to make decisions.
• The team is self-organising and does not rely on management to set and meet its goals.
• The team commits and takes responsibility for delivery and is prepared to help with any task that helps the team to achieve its goal.
• The team knows who the product owner is.
• Each sprint/iteration has a clear goal.
• All team members, including testers, are included in requirements workshops.
• Requirements documentation is barely sufficient and the team collaborates to clarify details as features are ready for development.
• Test cases are written up-front with the requirements/user story.
• There is a product backlog/feature list prioritised by business value.
• The product backlog has estimates created by the team.
• The team knows what their velocity is.
• Velocity is used to gauge how many user stories should be included in each sprint/iteration.
• Sprints/iterations are timeboxed to four weeks or less.
• Sprint budget is calculated to determine how many product backlog items/features can be included in the sprint/iteration.
• The sprint/iteration ends on the agreed end date.
• All tasks on the sprint backlog are broken down to a size that is less than one day.
• Requirements are expressed as user stories and written on a card.
• The team estimates using points which indicate the relative size of each feature on the product backlog/feature list.
• The team generates burndown charts to track progress daily.
• Software is tested and working at the end of each sprint/iteration.
• The team is not disrupted during the sprint/iteration.
• Changes are integrated throughout the sprint/iteration.
• Automated unit testing is implemented where appropriate.
• There is an automated build and regression test.
• Stretch tasks are identified for inclusion in the sprint/iteration if it goes better than expected.
• The Product Owner is actively involved throughout each sprint.
• All code changes are reversible and it is possible to make a release at any time.
• Testing is integrated throughout the lifecycle and starts on delivery of the first feature.
• Impediments that hold up progress are raised, recorded on the whiteboard and resolved in a timely fashion.
• When someone says ‘done’, they mean DONE! (ie shippable).
• The team uses the whiteboard to provide clear visibility of progress and issues on a daily basis.
• The sprint/iteration goal(s) is clearly visible on the board.
• All user stories and tasks are displayed on the whiteboard for the duration of the sprint/iteration.
• Daily scrums happen at the same time every day ? even if the scrum master isn’t present.
• The daily scrum is resticted to answering the standard 3 scrum questions and lasts no more than 15 minutes.
• There is a product demonstration/sprint review meeting at the end of each sprint/iteration.
• All team members, including testers and Product Owner, are included in the sprint/iteration review.
• The sprint/iteration review is attended by executive stakeholders.
• There is a sprint retrospective at the end of each sprint/iteration.
• Key metrics are reviewed and captured during each sprint retrospective.
• All team members, including testers, are included in the sprint retrospective meeting.
• Actions from the sprint retrospective have a positive impact on the next sprint/iteration.