【資料公開】スプリントレビュー Deep Dive
みなさんこんにちは。@ryuzeeです。 2023年1月11日-13日に開催のイベント「Regional Scrum Gathering Tokyo 2023」の登壇資料を公開します。 スプリントレビューは非常に重要なイベントです。 5つのイベントのなかでいちばん重要なイベントを選べと言われたら、僕はスプリントレビューを選びます。 スクラムはプロダクトを届けるためのものであり、プロダクトを成功させるにはプロダクト自体の検査と適応が必須だと思うからです。 一方で、スプリントプランニングの精度を上げようと頑張る割にスプリントレビューが雑に扱われる例が多くて懸念していました。 ということで、本セッションでは、スプリントレビューの目的や参加者、進め方、コツなどを深掘りしてみました。 みなさんの参考になれば幸いです。 忙しい方向けのまとめ スクラムチーム全員が参加しろ スクラムチームの外側のステーク
[Agile]スプリントのタスクに関するTips29個 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 Scrum CrazyというサイトでスプリントのタスクについてたくさんのTipsがまとめられているのでご紹介します。 Sprint Tasking Tips ここではTipsのタイトルだけ紹介しておきますので、詳しくは上記サイトを参照してください。 Scrum Crazyでは他にも色々なTipsがあるので是非見ておくと良いと思います。 正直に見積もり、見積りが正確であることに価値をおく環境を作ることタスクを見積もる際は時間で見積もることを強く推奨実時間ではなく理想時間を使うことが望ましいより粒度を小さくしたタスクにすることを強く推奨1日は5〜6理想時間とすること作業量を見積もるのであって期間を見積もるのではないできるだけアトミックな単位にタスクを分ける「作業中」の状態が2日以上にならないようにするタスクはチームで見積もるスプリント途中での再タスキン
![[Agile]スプリントのタスクに関するTips29個 | Ryuzee.com](https://cdn-ak-scissors.b.st-hatena.com/image/square/2739e548348eb41752b3cb6bf863f6de2d5fd0f4/height=288;version=1;width=512/https%3A%2F%2Fwww.ryuzee.com%2Fcontents%2Fblog%2Fimages%2F3959%2Fthumbnail.png)
スクラム・オブ・スクラムにおけるデイリーミーティング
みなさんこんにちは。@ryuzeeです。 大規模な体制でスクラムを行う場合、3〜9人の開発者を1開発チームとして、フィーチャー単位で開発チームを分割し、複数スクラムチーム間でスクラム・オブ・スクラムを行うのが定石です。 今回は、スクラム・オブ・スクラムにおけるデイリースクラムでのグランドルールを紹介しましょう。 元ネタはScrum of Scrum Ground Rulesです。 グランドルール通常のスクラムチームのデイリースクラムと同じように、素早く短い時間で行うべきである準備を済ませた上で時間通りに集まることまず最初に自分のスクラムチームの名前を述べるそしてチームについて述べる。チーム内の個人についてではない。チームにおける問題はミーティング中に報告されるが、解決策に関する議論は、他のチームの報告が終わってから行う。各チームの報告が終わったら、議論の話題は報告された問題、課題、取組に移
スクラムにおける技術的スパイクの進め方
みなさんこんにちは。@ryuzeeです。 スクラムでは、スプリントに投入するプロダクトバックログアイテムはReady（準備ができている）である必要があります （Readyとはどんな状態なのかについては以前に詳しく説明したので、そちらを参照してください）。 Readyにしておくことによって、成果の量が安定しプロダクトオーナーやステークホルダーにとっては予測精度が向上していきます。 Readyにする活動は単に受け入れ基準を用意したり、プロダクトバックログの内容を精緻化したり、並べ替えたりするだけではありません。 スプリント内でプロダクトバックログアイテムが完成する可能性を上げるために必要な活動すべてが含まれます。 そしてその中の1つが技術的な調査です。 スプリントでプロダクトバックログアイテムに着手してから実現方法を調べたり、技術的な制約によって大幅な方針転換したりするのでは遅い上に予測性が低
ベロシティに対する誤解 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 スクラムをはじめとしたアジャイル開発の見積りでよく使われるのがストーリーポイントです。 ストーリーポイントは研修でもよく聞かれるテーマであるとともに、誤解も多いものなので、今回基本からまとめて解説したいと思います。 なお、文脈の前提として、スクラムでの活用を想定しています。 ストーリーポイントとは？まずは、ストーリーポイントとは何なのかを見ていきましょう。 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』（Mike Cohn 著、安井力、角谷信太郎 訳、マイナビ出版、2009/1/29）の61ページから62ページにかけて、ストーリーポイントは以下のように定義されています。 ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような
プロダクトバックログ項目はReadyなものだけスプリントに投入するべきという話
みなさんこんにちは。@ryuzeeです。 プロダクトバックログはスクラムにおける生命線の1つです。 プロダクトバックログが良くないとプロダクトの価値がでなかったり、そもそもスクラムチームとして安定したデリバリーを行えません。 プロダクトバックログでよく起こる問題プロダクトバックログを管理する上でみなさんがよく知っているのは、並び替えをする、という点ですが、これだけではまったく不十分です。 単に並び替えだけをしたプロダクトバックログで、スプリントを始めてしまうと以下のようなことが起こります。 選択したプロダクトバックログアイテムの中身に対してプロダクトオーナーと開発チームの理解が違ってしまうそのためスプリントを開始した後に頻繁にプロダクトオーナーと会話をする必要が出てきてしまい、場合によっては本来の要求が別のものであることが判明するもしくは色々会話をしていたら、当初の想定以上に規模が大きいこ
プロダクトバックログアイテムの優先順位の付け方
みなさんこんにちは。@ryuzeeです。 プロダクトバックログアイテムの優先順位を決めるにはいくつかの方法があります。 Backlog Prioritization Techniquesにて、いくつかのやり方が説明されていましたので抜粋・意訳にてご紹介します。 どれを使うかは、そのプロダクトが自社製品かどうか、その製品の新規性の有無、開発の体制などなど、コンテキストに依存するところがあるので、どれが一番良いというのはありません。 ただ、分かりやすいという点では、狩野モデルは良いと思っています。 MoSCoW法M 絶対必要S できれば実装すべきC 他への影響がなければ実装できるとよいW 今回は実装しないが将来に実装するかもそれぞれの要求に対してMからWまでのタグをつける。 Mは優先順位がもっとも高く、Wは最も低いということになる。 ビジネス価値に基づく判断それぞれの要求は潜在的なビジネス上の
リリースプランニングの10個のTips
みなさんこんにちは。@ryuzeeです。 Release planning 10 Tipsを抜粋・意訳にてご紹介します。 スクラムにおいては、プロダクトバックログの重要性が極めて高いので、それをどうやってメンテナンスしていくか、という点について参考になると思います。 以前、コーチで行ってた現場で、「プロダクトバックログを最初に抽出して固定して一括請負契約できますか？」という質問を受けたことがありますが、アジャイルにおいては要件は可変パラメータなので、プロダクトバックログの固定自体はあり得ません。 プロダクトバックログは常時変化していることを認識することプロダクトプロダクトバックログアイテムの優先順位を継続的に付け直すこと次のスプリントのためのプロダクトバックログアイテムを継続的に準備することプロダクトバックログアイテムの個数は60〜70項目までにすることプロダクトオーナーは開発チームと一緒
プロダクトバックログ・グルーミングとはなにか？ | Ryuzee.com
プロダクトバックログは継続的に更新される生きたドキュメントである。 プロダクトバックログには、全ての機能要求、非機能要求を含むすべての要求を含んでいる。 なぜプロダクトバックログのリファインメントを行うのかプロダクトバックログリファインメントは極めて重要だ。以下のようなことに役立つ。 開発チームとプロダクトオーナーが大きなプロダクトバックログアイテムを小さいものに分割するのに役立つ。それによって個々のプロダクトバックログアイテムのスコープについてより理解が共有される。開発チームとプロダクトオーナーは長くて息切れするようなスプリントプランニングを避けることができる。それによって時間のムダを防げる。プロダクトオーナーによって追加された新たなプロダクトバックログアイテムや既存のプロダクトバックログアイテムをより小さいものに分割する。開発チームはより簡単にプロダクトバックログアイテムの見積りができ
プロダクトオーナーの重要な役割トップ７
プロダクトオーナーはチームにビジョンを伝え、プロダクトバックログにおける作業を説明することでチームをリードする。 プロダクトオーナーは、チームと直接コミュニケーションをとって、プロダクトバックログアイテムの優先順位付けを視覚的に行うことでプロジェクトをドライブする プロダクトオーナーはビジネス価値に基づいて作業を優先順位付けする。 スクラムは開発の意思決定をエンピリカルなデータに基づいて行うという点でユニークである プロダクトオーナーはチームと作業について交渉を行う。 各スプリントの最初にチームとプロダクトオーナーはそのスプリントで何に取り組むかを決めるために会う。 しかしこの取り組む作業は、プロダクトオーナーが単に割り当てするのではなく交渉によって決められる。 そしてプロダクトオーナーはチームが出しているベロシティいついては尊重しなければならない プロダクトオーナーはチームの質問に答えた
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロダクトオーナーの役割を1枚で紹介