※転載済み スプリント0実施物

優先度	タスク名	詳細	ステータス
# マストリスト	イベントのスケジュールの決定（どのイベントを何曜日に何時間やるか）	スプリントの期間（1週間など） スプリントプランニング（1ヶ月8時間、1週間2時間、PO参加1時間、タスク切りで1時間など） リファインメント（1週間2時間など） レトロスペクティブ（1週間30分、内部30分）、有名どころでいうとKPT	完了
	ワーキングアグリーメントもしくはチームルールの記載場所の決定		未完了
	ざっくりとマイルストーンまでのプロダクトゴールのPBI作る	POがビジネス目線で作成 開発チームが着手可能かどうかの判断をするときの最大サイズの決定 最大サイズの単位も決める（時間なのかポイントなのか）
	アーキテクチャ構成図（場所の確定はmust。記載の粒度は段々あげていく前提）
	gitブランチルールの決定	自動デプロイのCICDツール選定、モノレポなどを考慮しつつが望ましい
	スクラムガイド2020の確認（SMのみ）https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf	※完全な理解は難しいと思うので流し読みで2-3回が適当
	インフラパラメータ記載場所（awsなどでCDKを用いてい実装するならこれは不要）
	PBIの一旦の記載フォーマット決定	少なくとも　完了条件（DOD）　は記載する
	PBIの完了までのステータスフローの決定	開発メンバーの実装終わりステータスはデプロイ待ちステータスとし、POがレビューして良い状態はPOレビュー、それが終わると完了とする？など
	プロダクトゴールの決定	プロジェクトの期間と、それまでに何を成し遂げたいか、達成する肝となる指標は何か 例：デザインとページのレスポンススピードでは、ページのレスポンススピードを優先するなど
	スプリントレビューでSM（もしくはdev）が提示する資料のフォーマットの決定	このスプリントで何を開発したのか（インクリメント） 何に何時間かかったのか　など、チームの成長のために有効な指標、バグの原因分析などを入れるプロジェクトもある

優先度	タスク名	詳細	ステータス
# 優先度高リスト	自動テストをやるかの決定と、やる場合どのようにやるかの決定、もしくは記載場所だけでも決定
	受け入れの品質基準（コードカバレッジなど）を設定するかの決定と、設定する場合どうするか、もしくは記載場所だけでも決定
	コードレビューをするかの決定、する場合のルール（誰が、どういう観点で見るのか。レビュアーを固定した方がいいのか。何人が見るべきか。）の決定
	ざっくりと非機能要件のPBI切り（pbiを切るという最低限の記載でもよい）	脆弱性試験 負荷試験　などなど
	プログラミングの観点でのアーキテクチャ構成の記載場所の確定（デザインパターンなど）
	今後一定期間における使用環境バリエーションの確認、その相談を行うというpbiもしくはタスクの作成	開発環境、stg環境、prod環境は使用するタイミングがあるか、必要かなど）
# 優先度中	ローカル環境構築など、作業手順wikiの作成、少なくとも記載場所だけでも決定
# 優先度中	エクストリームプログラミングの読了（SMの）（スクラムとは厳密にいうと全く異なるものだが、より具体的なプラクティスが記載され、情報量も多く、スクラムを理解する上で有用。スクラムガイドだけでは記載や単語の意味が漠然としたところの疑問解決に役立てるように使用するのが良い）
# 優先度中	品質指標の見える化をするかどうかと、見えるようにする場合はどうするかを決める、少なくとも記載場所だけでも決定	コードカバレッジやコード重複など

備考

上記全てをスプリント0中に実施する必要があるというわけではない、
可能な限り検討して進め、残項目はスプリント1後などに少しづつも可能。
マストリスト（1-2週間以内に決めたいもの）
↓
優先度高リスト（スクラム開始後、1ヶ月以内に少なくとも相談まではしたいもの）
↓
優先度中リスト（スクラム開始後、1-3ヶ月以内に少なくとも相談まではしたいもの）
の順に記載