スプリント

スクラムの価値基準は、透明性、検査、適応です。 これを踏まえて考えると、障害や割り込みが起こったことをスクラムチーム全員が知っている状態であることが望ましいです。 例えば、開発者が障害や割り込みを受けて、プロダクトオーナーに知らせることなく対処している場合、最終的にスプリントゴールの達成があやうくなった時点で初めてプロ

最初のスプリントまでに多少の準備は必要です。 あれもこれも全部深堀すると時間がかかってムダも多いので、以下に挙げたような項目のなかから必要な項目に絞って準備します。 一般的に準備にかける時間は2週間～1か月程度です。準備に時間をかけすぎるとフィードバックを受けるタイミングが遅くなるので、スプリント1を始めるのに十分な状

スクラムガイドでは、スプリント期間を一定に保つことについて直接は理由の明記はありませんが、以下のような理由です。 イベントの開催時間が明示的になるので、関係者間の予定調整が必要なくなる 同じリズムで仕事の進捗をふりかえることができるので、チームのパフォーマンスを計測したり、比較したりしやすい 同じリズムで仕事を進める

スクラムではリリースについて言及がありません。 つまりスプリントごとにリリースしなければいけないという決まりもないですし、スプリントの途中でリリースしてはいけないという決まりもありません（スプリント中にリリースし、スプリントレビューでリリース済みのものをレビューしても構いません）。 いつリリースするかはプロダクトの種類

緊急事態の内容や発生源によって対応は変わります。 プロダクトの外的状況に大きな変化があったり、スプリントゴールに意味がなくなったような場合であれば、プロダクトオーナーがスプリントのキャンセルを判断することもあります。 大規模な障害やバグが発生して、すべてに優先した対応が必要な場合なども同様です。 開発者側で発生したので

ときには、スプリントバックログがすべて完成し、それでも時間が余ってしまうことがあります。 この場合にどうするかは、スクラムガイドでは決められていません。 一方で、スプリントは固定の期間であり、他のイベントとは違って、早く終わったからといって時間を短縮してはいけません。 つまり、余った時間をどう使うかはチームで決めること

スプリントプランニングやスプリントレビューは定期的に実施することにメリットがあるので、基本的に曜日を固定することをお勧めします。 つまり祝祭日があった場合は、その分スプリントの稼働日数は減ります。 開発チームが使える時間も減るので、計画ではそれを考慮して、取り組むプロダクトバックログアイテムを減らすのが一般的です。 ま

5年前くらいまでは最初は2週間スプリントにしているチームが多かったと思うのですが、最近では1週間スプリントにすることをお勧めしています。 主な理由は以下のとおりです。 レトロスペクティブ（ふりかえり）が頻繁にあるので改善が進む 計画の精度が高くなる 例え失敗しても一週間で済むので実験しやすい ベロシティの数字がすぐ出

これは複数のプロダクトバックログアイテムを平行して開発しているときに起こります。例えば個人にプロダクトバックログアイテムを割り当てたり、スプリントのなかでミニウォーターフォールをやっていたりする場合が該当します。 このようなやり方をするとスプリントでインクリメントが完成しないリスクが高くなります。インクリメントが完成し

新規プロダクトの場合は、最初のスプリントの開始前に、スプリント0と呼ばれる助走期間をとってビジョンを明確化したり、初期の要件を収集したり、アーキテクチャを検討したりすることがあります。これについては時間を限定して実施する分には構いません。準備不足で決まっていないままに進めると、スプリントが空回りするためです。 一方で、

みなさんこんにちは。@ryuzeeです。 スプリントでの作業の進め方について以下のような質問を頂きました。 2週間スプリントでスクラムに取り組んでいます。 スプリントの中では、要件定義→開発→テスト項目作成→テスト→ユーザー受け入れテスト→リリースの順番に進めていますがミニウォーターフォール型との違いが分かりません。ど

みなさんこんにちは。@ryuzeeです。 実際のプロジェクトやプロダクトでスクラムを利用している場合、リリースの前に「リリーススプリント」と呼ばれる期間を設けて、残作業を行うことがあります。 これが何なのかについて見ていきたいと思います。 なお、リリーススプリントは、スクラムガイドなどで定められているスクラムの要素では

みなさんこんにちは。@ryuzeeです。 職業柄スクラムを始めたばかりのチームを支援することがよくあります。 そのような状況で、ロールの明確化や初期のプロダクトバックログの準備とあわせて話題にのぼることが多いのが、スプリントの期間をどうするかです。 そして、多くの場合、1週間スプリントを提案しています。 今回はなぜ1週

みなさんこんにちは。@ryuzeeです。 スプリントをずっと回していると、「いつもスプリントに追われている気がする」「一回立ち止まってゆっくり考えたい」「情報共有ができていない気がするので整理したい」「技術検証をもっとやりたい」「勉強時間をとりたい」といった話を聞くことがあります。 それに対して、どのように対処していく

みなさんこんにちは。@ryuzeeです。 元記事はLichard Lawrence氏のWhy Longer Sprints Probably Won’t Helpです。 良記事でしたので抜粋・意訳にてご紹介します。 本文に入る前に若干前提事項を補足しておきます。 以下で言っている「スプリント期間を伸ばす」というのは、

みなさんこんにちは。@ryuzeeです。 Peter Stevens氏が行ったオンライン調査（調査母数は85）をもとにしてチームのサイズとスプリント期間とプロダクトバックログアイテムの数におけるスプリントの成功への関連について以下で述べているので、それを元に考察してみましょう。 Success Factors in a

みなさんこんにちは。@ryuzeeです。 スプリントプランニングでは、スプリントの終了までに「どのプロダクトバックログアイテムを完了させるか」を計画します。 このコミットとは何なのか？先日のCertified Scrum Product Owner研修でジェフ・サザーランドさんに以下のどれなのかを聞いてみました。 ス

みなさんこんにちは。@ryuzeeです。 Scrum Allianceのメーリングリストで、9日間のスプリントにおけるタスクカンバンの動きをビデオで撮影したものが投稿されていましたが、これが秀逸なのでご紹介します。 タスクカンバンの前にビデオと時計を定点設置して、休日も含めてずっとビデオを回しっぱなしで撮影したようです