More than 5 years have passed since last update.

スクラムにおける各イベントの狙いとその補足

スクラム

Last updated at 2019-09-13Posted at 2019-07-22

はじめに

ちょっとひと段落したので、スクラムについての理解をまとめてみたくなった。
「スクラムガイド」をベースに、個人的に調べた内容を補足しつつ、各プロセスは何を狙いにしているのかを整理してみた。
記事中の画像は基本的に「LeSS」から取得しています。

注意事項

個人的理解＋推測もりもりです。
「自分はこう思う！」とかあればぜひコメントください！
もっと簡潔にまとめるはずだったのに、だいぶ長くなった！

前提

スクラムガイドがベース。読んだことない人は、先にそっち読んでください。
「スクラムイベント（デイリースクラムとか）」に絞って整理します。（スクラムガイド解説みたいになると長すぎるので）
- また、細かい例外（スプリントの中止など）も割愛してます。（長くなりすぎるので・・・）

スクラムイベント

各イベントに対して、スクラムガイドに記載された内容から、「イベントを構成する要素」を抜粋し、似たような要素でまとめてます。
まとめた「イベントを構成する要素」に対して、「狙い」を整理していきます。

スプリント

◆基本的な定義◆

「完成」した、利用可能な、リリース判断可能なプロダクトインクリメントを作る。

スプリントは、スプリントプランニング・デイリースクラム・開発作業・スプリントレビュー・スプリントレトロスペクティブで構成される。

狙い	補足
プロダクト評価	「我々が作っているものが価値があるのか？」を可能な限り早く評価することでプロダクトの方向性をコントロールする。
リスク管理	「（ウォーターフォールにおける）システムテストで発生した方式設計起因の不具合」などの致命的な手戻りを早期に検知することで、リスクコントロールを容易にする。基本的に、スプリント回数を経るごとに、リスクが減っていくようにコントロールする。
進捗予測	「動くもの」で評価することによって、システムの進捗を定量的に評価する。スプリント回数を経るごとに、進捗予測の精度は高まる。

スクラムを導入する状況によって、どの要素が大きいのかは変わってくると思う。
なお、リスク管理が狙いだからといって、「リスクの高いもの（難しいもの）」だけで最初のスプリントを固めると混乱が大きい。
「リスクが低いもの（簡単なもの）」でリズムを取りつつ、「リスクが高いもの（難しいもの）」をまぶすのがちょうど良い気がしている。（当然、プロジェクトの状況にはよるだろうけど。）

◆期間に関する定義◆

1か月以下のタイムボックス

開発中はスプリントの長さは常に一定

狙い	補足
リスク管理	期間の長さ＝リスクの大きさ
進捗予測	「一定期間」での「成果物」をベースに、システムの進捗を定量的に評価する。スプリント回数を経るごとに、進捗予測の精度は高まる。

リスク管理については、以下の通り本文に根拠が示されている。

スプリントが長すぎると、開発対象の定義が変更されたり、複雑になったり、リスクが増大したりする可能性がある。ゴールに対する進捗を少なくとも 1 か月ごとに検査・適応することで、予測可能性が高まるのである。また、リスクも 1 か月分のコストに収まるようになる。

個人的には、カオスな状況ほど、タイムボックスは短く切った方がいいと思う。（検査・適応のサイクルが早く回るので）
ただ、タイムボックスが短いほど、コミュニケーションコストを大きく感じるので、タイムボックスの長さに応じて、各イベントのやり方は見直した方がいいと思う。
（1dayスプリントなら、全イベントで30分に納めるとか。）

◆その他注意事項◆

スプリントゴールに悪影響を及ぼすような変更を加えない。

これ、説明する必要あるのか？
進捗予測が崩れるとか、理由づけはできなくもないけど、シンプルにダメでしょ？でいい気がする。

品質目標を下げない。

これも説明する必要あるのか？上記と同じく、シンプルにダメでしょ？でいい気がする。

もし、ハードルが高すぎて、1スプリントでクリアできないような品質目標だとするなら、それはチームのカイゼンポイント。
そのハードルを1スプリントで達成するためにどうすべきかを考え、いつまでにそれを達成するのか？それまではどのように対処するのか？を整理するのが大事。

学習が進むにつれてスコープが明確化され、プロダクトオーナーと開発チームの交渉が必要になる可能性がある。

これは、「何かを狙いとした構成要素」じゃなくて、「結果的にこういう性質」であるという要素だと解釈。

スプリントプランニング

◆基本的な定義◆

スプリントが 1 か月の場合、スプリントプランニングのタイムボックスは最大で 8 時間である。

狙い	補足
最大効率化	【時間対効果】時間は有限なので、時間に収めるように活動していく意識が必要。この時間枠に収まらないなら、「そもそもリファインメントができてない」可能性が高い。

スクラムでは「タイムボックスの厳守」がよく言われます。個人的には以下が理由だと思っています。

「投下時間」に対して「質」は特定の時点までは上がっていくだろうが、そこからは落ちていく。
特に「計画」は不安から過剰に時間を掛けがちなので、タイムボックス厳守を前提にすることで、過剰な計画を避けることが狙い。

なお、「計画」と「実行」のバランスはチームによって異なるかもしれないが、ひとまずの目安として提示された 8 時間を目標にするのが良さそう、と感じてます。

スプリントプランニングのインプットは、プロダクトバックログ、最新のプロダクトインクリメント、開発チームが予想するキャパシティと過去の実績である。

プロダクトバックログ：ここから、このスプリントで何をするのかを選ぶから。
最新のプロダクトインクリメント：何を価値として受け止められているかを知るため。
開発チームが予想するキャパシティと過去の実績：作業量の枠を決めるため。

スプリントプランニングでは、以下の質問に答える。
- スプリントの成果であるインクリメントで何を届けることができるか？
- インクリメントを届けるために必要な作業をどのように成し遂げるか？

狙い	補足
最大効率化	最大効率を上げるために、「短期目標の具体化」と、「終わらせ方の具体化」を行う。

「終わらせ方の具体化」については、以下の図がイメージしやすいかも。

※slideshare「フロー効率性とリソース効率性について」より

◆スクラムチームの役割◆

スクラムチームはみんなで協力して、スプリントの作業を理解する。

スクラムチームがスプリントゴールを設定する。スプリントゴールとは、プロダクトバックログを実装することで実現するスプリントの目的であり、開発チームがインクリメントを開発する指針となるものである。

開発チームの作業が多すぎたり少なすぎたりした場合は、選択されたプロダクトバックログアイテムについて、開発チームとプロダクトオーナーで話し合う。あるいは、技術やドメインに詳しい人を招待してアドバイスを求めることもできる。

協力するのも、目標を設定するのも、チーム外の支援を要請するのも、わざわざ狙いを説明する必要は無い気がするので割愛。

◆開発チームの役割◆

ちょっと多いので、まとめてから、理解する。

「次のスプリントでやること（確実にやりきると信じれる量）」を決める

プロダクトバックログから選択するアイテム数については、開発チームが責任を持つ。

スプリントで何を達成するかを評価できるのは、開発チームだけである。
作業の規模や工数はバラバラであっても構わないが、開発チームが次のスプリントで実現できそうなものを計画する。
開発チームは、スプリントで開発できそうな機能を予想する。

狙い	補足
進捗管理	無理は続かない。一定の歩幅でないと、進捗予測ができない。
最大効率化	【プロセスの最適化】無理・ムラは長期的に見て効率を悪化させる。

無理・ムラ自体は課題と解釈し、カイゼン対象と認識する。避けているだけではチームの成長につながらない。

作業を分解する

開発チームは、プロダクトバックログを動作するプロダクトインクリメントに変えるために必要なシステムと作業の設計から着手する。

開発チームがスプリントの最初の数日間で行う作業については、スプリントプランニングで作業に分解する。
作業の単位は 1 日以下にすることが多い。

狙い	補足
進捗管理	動くモノだけが進捗基準足り得る。動くモノを動かすために、移行などのついつい忘れがちな作業から検討をはじめるべき。
最大効率化	【ムダの排除】いきなり全てをタスクに分解する必要はない。基本的には直近数日分でよい。その結果で、また変わっていくかもしれない。（スプリント期間中の全てが見通せている場合は、その限りではない。）

自己組織化

開発チームは自己組織化して、スプリントバックログの作業を引き受ける。

これはスプリントプランニングだけでなく、必要であればスプリントでも行う。
スプリントプランニングが終了するまでに、開発チームは自己組織化したチームとして、どのようにスプリントゴールを達成し、どのように期待されるインクリメントを作成するかをプロダクトオーナーとスクラムマスターに説明できなければいけない。

狙い	補足
最大効率化	【フロー効率】スプリントバックログにある全ての作業を、開発チームが独力で実施できるようにすることで、最大効率を目指すことが出来る。

プロダクトオーナーとスクラムマスターに説明できるくらいイメージの具体化ができているのか？がポイントな気がする。

◆プロダクトオーナーの役割◆

プロダクトオーナーは、スプリントで達成すべき目的と、完成すればスプリントゴールを達成できそうなプロダクトバックログアイテムについて検討する。

プロダクトオーナーは、選択したプロダクトバックログアイテムの明確化やトレードオフを支援する。

狙い	補足
最大効率化	【フロー効率】スプリントバックログにある全ての作業を、開発チームが独力で実施できるようにすることで、最大効率を目指すことが出来る。

最終的な狙いは、開発チームの自己組織化だと思っている。目標とPBIの最終決定権はプロダクトオーナーにありつつ、責任はスクラムチームで共有している認識。

◆スクラムマスターの役割◆

スクラムマスターは、参加者に目的を理解してもらうようにする。

スクラムマスターは、スクラムチームにタイムボックスを守るように伝える。

目的は当たり前。
タイムボックスについてはすでに触れているので割愛。

デイリースクラム

※画像はLeSS「Figure 5. Visual Management - Sprint Backlog tasks on the wall」より

◆目的◆

デイリースクラムは、以下によって、開発チームのプロジェクト知識のレベルを向上させるものである。
- コミュニケーションの改善
- その他のミーティングの除外
- 開発における障害物の特定・排除
- 迅速な意思決定の強調・助長

原文はちょっと分かりづらいので、「より高レベルの知的活動ができるようにする」と解釈してます。
その上で、「そのためには、コミュニケーションを改善したり、作業に集中できるようにしたり、迅速な決定が大事！」と解釈してます。

コレ自体が狙いなので、補足も要らないと思う。

◆目標◆

前回のデイリースクラムから行なった作業の検査と今後のスプリント作業の予想をする。
- それによって、チームのコラボレーションやパフォーマンスを最適化する。
- スプリントゴールとスプリントバックログの進捗を検査する。
- スプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない。

狙い	補足
進捗管理	【検査】スプリントゴールを達成できるかどうかの見通しがあるかを確認する。
課題管理	【適応】スプリントゴールを達成できない可能性がある場合は、その問題の存在を共有し、対処を考える。

スクラムの理論にある「透明性・検査・適応」の3本柱のウチ、検査・適応の場である。

◆やり方◆

毎日、同じ時間・場所で、次の24時間の計画を、15分間で行う。
- 開発チームのための 15 分間のタイムボックス
- 開発チームは、次の 24 時間の作業を計画する。
- 毎日、同じ時間・場所で開催

狙い	補足
最大効率化	【時間対効果】毎回、時間と場所が変わるということは、場所取りなどにムダに時間を割いている可能性が高い。15分程度ならスタンド・アップでも十分できるはず。
進捗管理	【検査】同じタイミングで、同じ間隔を計画する癖をつけていれば、どんどん見通し精度は上がっていくはず。24時間でどこまでできるのか、だんだん見えるようになってくる。
最大効率化	【時間対効果】時間は有限なので、時間に収めるように活動していく意識が必要。この時間枠に収まらないなら、「細かいことを話過ぎている」可能性が高い。細かい話は、デイリーの後で会話する。

◆補足情報◆

デイリースクラムの構成は、開発チームが設定する。
- スプリントゴールを目指している限り、他のやり方で行なっても構わない。
- 質問を使うチームもあれば、議論ベースで進めるチームもある。
- 質問の例
- 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？
- 開発チームがスプリントゴールを達成するために、私が今日やることは何か？
- 私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか？

狙い	補足
自己組織化	あくまで日々の活動は開発チームの責任範囲である。そもそも画一したやり方がどのチームにもフィットするということは無い。自身で望ましいやり方を見つけていく組織を目指す。

よく言われている質問「スプリントゴール達成のために、昨日やったこと/今日やること/障害の有無」は、あくまでも例です。スクラムプロセスとして、「こうやりなさい！」と行っている訳ではないです。

また、「スプリントゴール達成のために」という前置きを捨てて、「昨日やったこと/今日やること」だけを聞いているケースをよく聞きます。それは、ただの報告会になるだけだし、デイリースクラムの狙いが全然達成できてないので、むしろやらないほうが生産性が上がるかもしれないですね。

開発チームやチームメンバーは、デイリースクラムの終了直後に集まり、スプリントの残作業について、詳細な議論・適応・再計画を行うこともある。

狙い	補足
自己組織化	あくまで日々の活動は開発チームの責任範囲である。そもそも画一したやり方がどのチームにもフィットするということは無い。自身で望ましいやり方を見つけていく組織を目指す。
最大効率化	【時間対効果】時間は有限なので、時間に収めるように活動していく意識が必要。この時間枠に収まらないなら、「細かいことを話過ぎている」可能性が高い。細かい話は、デイリーの後で会話する。

15分でやる範囲と、そうじゃない範囲をちゃんと見極めてやりましょう。そうじゃないと会議が伸びるばかりになります。
デイリースクラムじゃないから、「無制限で時間かけていい」という訳でもないです。時間対効果をちゃんと考えましょう。

◆スクラムマスターの役割◆

スクラムマスターは、開発チームにデイリースクラムを開催してもらうようにする。ただし、デイリースクラムを開催する責任は開発チームにある。

スクラムマスターは、デイリースクラムを 15 分間のタイムボックスで終わらせるように開発チームに伝える。
デイリースクラムは開発チームのためのミーティングである。それ以外の人たちが参加する場合、開発チームの邪魔にならないようにスクラムマスターが配慮する。

これは割とそのままなので、割愛。。。（ちょっと疲れてきた。）

スプリントレビュー

◆基本的な定義◆

スプリントレビューとは、スプリントの終了時にインクリメントの検査と、必要であればプロダクトバックログの適応を行うものである。

これはステータスミーティングではなく、略式のミーティングである。
- （私的補足）「ステータスミーティング(status meeting)＝公式の進捗会議」ではなく「略式ミーティング(informal meeting)＝ラフに話し合う場」。
スプリントが 1 か月の場合、スプリントレビューは最大 4 時間である。

狙い	補足
最大効率化	【価値への追求】「進捗管理や進捗状況へのフィードバック（ステータスミーティング）」ではなく、「プロダクトの価値を最大化するためのフィードバック」を求める打ち合わせである。
最大効率化	【時間対効果】時間は有限なので、時間に収めるように活動していく意識が必要。この時間枠に収まらないなら、「余計な話をしている」可能性が高い。本当に必要なトピックだけに絞る。

「遅れているのか？遅れているならどのようにキャッチアップするのか？」みたいなのは、ステータスミーティング。
スプリントレビューでは「現在ここまで出来上がりました。プロダクトについて今後の開発優先度はこう考えている。プロダクトの価値向上を考えると、追加/修正したほうが良い機能はありそうか？」ってのを話すイメージ。

全員が一丸となって考えることが重要。スプリントレビューは検収（受入チェック）のようなイベントではない。

組織でステータスミーティングが求められる場合は、別途開催のほうが安定する気がする。
会議体が増えるのは望ましくないけど、ステータスミーティングは開発チームにとってはノイズが多すぎる気がする。
（開発チームが参加するメリットはあるだろうけど、時間帯効果としては薄いだろうから、事後連携でも十分だと思っている。）

◆スプリントレビューでやること◆

グループ全体で次に何をするべきかを議論し、次のスプリントプランニングに価値のあるインプットを提供できるようにする。
- 参加者は、スクラムチームとプロダクトオーナーが招待した重要なステークホルダーである。
- 市場やプロダクトの利用状況によって、次に行うべき最も価値の高いことが変更される可能性をレビューする。
- 次にリリースするプロダクトの機能や性能のスケジュール・予算・可能性・市場をレビューする。

プロダクトバックログの調整
- スプリントレビューの成果は、次のスプリントで使用するプロダクトバックログアイテムが含まれた改訂版のプロダクトバックログである。
- 新たな機会に見合うように、プロダクトバックログを全体的に調整することもある。

狙い	補足
最大効率化	【フロー効率】フロー効率を意識して、必要な関係者を呼ぶ。（ステークホルダーは多すぎると議論が踊るので、重要なステークホルダーに絞る）
最大効率化	【価値への追求】「進捗管理や進捗状況へのフィードバック（ステータスミーティング）」ではなく、「プロダクトの価値を最大化するためのフィードバック」を求める打ち合わせである。

「プロダクトの価値」ってのは、「市場にとっての価値」を指すので、市場を意識する必要がある。

「フロー効率」は以下が分かりやすいかも。

※slideshare「フロー効率性とリソース効率性について」より

◆プロダクトオーナーの役割◆

プロダクトオーナーは、プロダクトバックログアイテムの「完成」したものと「完成」していないものについて説明する。

プロダクトオーナーは、現在のプロダクトバックログの状況を説明する。（必要であれば）現在の進捗から、可能性のある目標とデリバリーの日程を予測する。

狙い	補足
情報共有	「プロダクトバックログの現状」と「未来予測（マイルストーン）」について説明する。

全員に対して「現状」と「未来」の話をするのがプロダクトオーナー。
「今回スプリントの成果」は開発チームが説明する。

◆開発チームの役割◆

開発チームは、スプリントでうまくいったこと、直面した問題点、それをどのように解決したかを議論する。

開発チームは、「完成」したものをデモして、インクリメントに対する質問に答える。「完成」の定義にプロダクト機能のリリースが含まれていれば、それらを表示してレビューしてもらう。

狙い	補足
情報共有	「良いところ、課題、対処内容」と「プロダクトインクリメント」について説明する。

「良かったこと、課題、対処内容」の共有については、いろんな解釈があるっぽい。レトロスペクティブとの差異についてもかなり議論されている。答えは出てないっぽい。

意見抜粋

結果(プロダクト)に対しては、スプリントレビューで。プロセスに対しては、レトロスペクティブで。
開発チームを褒める時間として使っている。
どうやろうとしても細かい話になるし、ステークホルダーはそんなのに興味ないから（what went wellについては）取り上げない。
関係者に、システム開発の背景を共有するためにやっている。

個人的解釈

ステークホルダーに対してのリスク/課題の説明（業務インパクトをベースとしたビジネス影響を中心に）
- システム屋目線ではなく、ビジネスレベルでの影響で会話をする。
「開発チームへの信頼感」「開発チームの自信」の醸成（明示的or暗示的）
- 信頼感/自信の欠如は、様々なコミュニケーションコストになって現れるため、その予防として用いる。

『ステークホルダーに対してのリスク/課題の説明』は、普段開発者が意識しないレベル感で説明が必要になるので、少し苦戦することが多い。
『「開発チームへの信頼感」「開発チームの自信」の醸成』は、わりとちゃんとしたコミュニケーションが取れていれば普通に醸成される印象。

◆スクラムマスターの役割◆

スクラムマスターはスプリントレビューが確実に開催されるようにして、参加者には目的を理解してもらうようにする。

スクラムマスターは関係者全員にタイムボックスを守るように伝える。

割愛。

スプリントレトロスペクティブ

◆基本的な定義◆

スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。
- 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。
- うまくいった項目や今後の改善が必要な項目を特定・整理する。
- スクラムチームの作業の改善実施計画を作成する。
- 改善はいつでも実施可能だが、スプリントレトロスペクティブは検査と適応に集中するための公式な機会である。

スプリントレトロスペクティブは、スプリントレビューが終わって、次のスプリントプランニングが始まる前に行う。
スプリントが 1 か月の場合、スプリントレトロスペクティブは最大 3 時間である。

狙い	補足
改善観点での検査	そのままなので、補足することがない・・・
最大効率化	【時間対効果】時間は有限なので、時間に収めるように活動していく意識が必要。この時間枠に収まらないなら、「余計な話をしている」可能性が高い。本当に必要なトピックだけに絞る。

◆具体的に何をするのか？◆

プロダクト品質を向上させる方法を計画する
- スプリントレトロスペクティブでは、スクラムチームは作業プロセスの改善や「完成」の定義の調整によって、プロダクトの品質を向上させる方法を計画する。
- ただし、プロダクトや組織の基準と衝突しないように適切に行う。
- スプリントレトロスペクティブが終わるまでに、スクラムチームは次のスプリントで実施する改善策を特定しなければいけない。
- これらの改善策の実施は、スクラムチーム自体の検査に対する適応になる。

狙い	補足
プロダクト品質向上	プロダクトの価値を上げるのはPBI。レトロスペクティブで議論のメインにするのは、「作り方（品質）」。

「プロダクトや組織の基準と衝突しないように適切に行う。」については、衝突するようなら組織側の基準を調整するなどのアクションも視野に入れたほうが良いと思っています。なかなか難しいですが。

◆スクラムマスターの役割◆

当たり前の話
- スクラムマスターは、このイベントが確実に開催されるようにする。また、参加者に目的を理解してもらうようにする。
- スクラムマスターは、全員にタイムボックスを守るように伝える。

意識してないと忘れそうなこと
- スクラムマスターは、スクラムのプロセスを説明するために、チームメンバーとして参加する。
- スクラムマスターは、このミーティングがポジティブで生産的になるようにする。
- スクラムマスターは、次のスプリントが効果的で楽しいものになるように、開発チームにスクラムプロセスフレームワークの範囲内で開発プロセスやプラクティスを改善してもらう。

スクラムマスターなので割愛。
ただ、「スクラムプロセスフレームワークの範囲内で」という前提はそこまでこだわらなくてい良いんじゃないかなぁ・・・とか思っちゃう。

まとめ

まとめは最初に書くのが基本ですが、本記事は全部見て欲しいから、一番最後にしてます。

管理・評価系

狙い	補足
プロダクト評価	「我々が作っているものが価値があるのか？」を可能な限り早く評価することでプロダクトの方向性をコントロールする。
プロダクト品質向上	プロダクトの価値を上げるのはPBI。レトロスペクティブで議論のメインにするのは、「作り方（品質）」。
改善観点での検査	そのままなので、補足することがない・・・
リスク管理	「（ウォーターフォールにおける）システムテストで発生した方式設計起因の不具合」などの致命的な手戻りを早期に検知することで、リスクコントロールを容易にする。基本的に、スプリント回数を経るごとに、リスクが減っていくようにコントロールする。
リスク管理	期間の長さ＝リスクの大きさ
進捗予測	「一定期間」での「成果物」をベースに、「動くもの」で評価することによって、システムの進捗を定量的に評価する。スプリント回数を経るごとに、進捗予測の精度は高まる。
進捗管理	【検査】スプリントゴールを達成できるかどうかの見通しがあるかを確認する。
課題管理	【適応】スプリントゴールを達成できない可能性がある場合は、その問題の存在を共有し、対処を考える。

最大効率化系

狙い	補足
最大効率化	最大効率を上げるために、「短期目標の具体化」と、「終わらせ方の具体化」を行う。
最大効率化	【プロセスの最適化】無理・ムラは長期的に見て効率を悪化させる。
最大効率化	【ムダの排除】いきなり全てをタスクに分解する必要はない。基本的には直近数日分でよい。その結果で、また変わっていくかもしれない。（スプリント期間中の全てが見通せている場合は、その限りではない。）
最大効率化	【フロー効率】スプリントバックログにある全ての作業を、開発チームが独力で実施できるようにすることで、最大効率を目指すことが出来る。
最大効率化	【フロー効率】フロー効率を意識して、必要な関係者を呼ぶ。（ステークホルダーは多すぎると議論が踊るので、重要なステークホルダーに絞る）
最大効率化	【時間対効果】時間は有限なので、時間に収めるように活動していく意識が必要。
最大効率化	【価値への追求】「進捗管理や進捗状況へのフィードバック（ステータスミーティング）」ではなく、「プロダクトの価値を最大化するためのフィードバック」を求める打ち合わせである。
最大効率化	【時間対効果】時間は有限なので、時間に収めるように活動していく意識が必要。この時間枠に収まらないなら、「余計な話をしている」可能性が高い。本当に必要なトピックだけに絞る。

その他

狙い	補足
自己組織化	あくまで日々の活動は開発チームの責任範囲である。そもそも画一したやり方がどのチームにもフィットするということは無い。自身で望ましいやり方を見つけていく組織を目指す。
情報共有	「プロダクトバックログの現状」と「未来予測（マイルストーン）」について説明する。
情報共有	「良いところ、課題、対処内容」と「プロダクトインクリメント」について説明する。

一部まとめてしまっていますが、だいたいこんな感じ。
ここらへんを意識していきたいところ。

さいごに

何度も読んでるつもりでしたが、「結構読み飛ばしてるなー」ってのが正直な感想でした。

文章全部コピーして、一行ずつにして、似たような分類でまとめて、狙いを整理して・・・
3日くらいかけちゃいましたが、個人的には凄く勉強になりました。
皆さんの考えあれば、是非教えて下さいー。

以上です。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up