投稿日
スプリント運営ガイド
もくじ
- 概要
- 基本ルールと前提
- 参考文献
- スプリント全体計画
- 受託開発での注意点
- スプリントの運営
- 前提条件
- スプリントワークフロー
- スプリント計画ミーティング
- 日々の作業
- プロダクトバックログリファインメント
- スプリントレビュー
- スプリントレトロスペクティブ
- こんなときには…
- スプリント内でストーリーが終わりきらない
- ストーリーに足りないタスクがみつかった
- プロダクトマネージャ
- 役割
- ストーリー分割チートシート
- 良いストーリーの基準 : INVEST
- ストーリー分割パターン
- 朝会
- スプリントレトロスペクティブ
- はじめに
- レトロスペクティブの流れ
- レトロスペクティブ実施の注意点
- レトロスペクティブアセスメントシート
- 参考文献
- 良いタスクの基準:SMART
- Specific
- Measurable
- Achievable
- Relevant
- Time-boxed
こんなときには…
スプリント内でストーリーが終わりきらない
スクラムではチームの自律を促すので、計画に無理があったということで、次のスプリントのベロシティを下げがちです。 明らかにチームの実力が足りない場合はやむを得ませんが、こういう事象が起こるたびに、安直にベロシティを下げるのはチームの生産性を必要以上に落とすことにつながります。 例えば以下の点を見なおして、次スプリントでベロシティの向上につながるかどうか試行してみてください。
- ストーリーの終了条件が適切であるか?
- お決まりのパターンでないタスクを単独作業でやってハマっている、なんてことがないか?
- タスクに落ちていない”xxの準備作業”みたいなものが無いか?
- Impedimentsが溜まりすぎて心的負担が大きくないか?
そして、プロダクトマネージャは自ら率先してコードを書きチームを救うことを躊躇うべきではありません。他人に作らせてレビューに終始するよりも、自らペアプロした方が生産性高いのではないですか?
ストーリーに足りないタスクがみつかった
「これやらないと終わりとは言えないし…」 個別判断せず、プロダクトマネージャにエスカレーションしてください。
以下の選択肢がありえます。
- タスクをいれかえ、そのスプリントの中で実装する。
- プロダクトバックログとしてあげ、後のスプリントで実装する。
- そもそも足りないという認識自体が杞憂である。