スクラムチーム（Scrum Team）はプロダクトバックログ（Product Backlog）というリストの一番上の項目を、次の（あるいは最初の）スプリントで開発して完成させます。ごくごく簡単に言うと、「このスプリントで作ると決めたプロダクトバックログ」が、スプリントバックログです。
Scrum.org のスクラムガイドによると、スプリントバックログについて次のように書かれています。
スプリントバックログは、スプリントゴール（なぜ）、スプリント向けに選択されたいくつかのプロダクトバックログアイテム（何を）、およびインクリメントを届けるための実⾏可能な計画（どのように）で構成される。
スプリントバックログは、開発者による、開発者のための計画である。スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで⾏う作業がリアルタイムに反映される。
https://www.scrum.org/resources/scrum-guide
これによると『「作ると決めたプロダクトバックログ」だけがスプリントバックログではない』ということがわかります。その他に、スプリントゴールと計画を合わせてスプリントバックログと呼びます。
なぜ作るのか？何を作るのか？どのように作るのか？を合わせてスプリントバックログバックログなのですね。
この「計画」については Azure DevOps などのシステムを使っているスクラムチームであれば、特に意識していなくても扱うことになると思いますが、「スプリントゴール」については意識していないスクラムチームが多いかもしれません。また、バックログの選択の仕方やタスクの扱い、リアルタイムに更新できているかどうかについても、慣れるまではなかなか難しいところがあります。それぞれのポイントについて、もう少し詳しく見てみましょう。
続きを読む
スクラムチーム（Scrum Team）はプロダクトバックログ（Product Backlog）というリストの上から順に開発を行います。
Scrum.org のスクラムガイドによると、プロダクトバックログについて次のように書かれています。
プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの⼀覧である。これは、スクラムチームが⾏う作業の唯⼀の情報源である。
https://www.scrum.org/resources/scrum-guide
この文章に Scrum チームがどのように「作りたいもの」を管理して、開発を行っていくか？ということが、とても明確に表現されています。ただ（スクラムガイド全般にそうですが）、Scrum を理解してから読まないとピンとこないくらい短い文章になっていますよね。それぞれのポイントについて、もう少し詳しく見てみましょう。
続きを読む
スクラムチーム（Scrum Team）のプロダクトオーナー（Product Owner）は、これから作るプロダクトがどうなっていればユーザーにとって価値があるか？ということを考え、開発者に示す役割です。プロダクトオーナーは開発者（Developers）にプロダクトゴール（Product Goal）を示すことで、プロダクトの価値を高めていきます。
Scrum.org のスクラムガイドによると、プロダクトオーナー（PO）について次のように書かれています。
プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化することの結果に責任を持つ。
プロダクトゴールを策定し、明⽰的に伝える。
https://www.scrum.org/resources/scrum-guide
またスプリントゴールについては次のように書かれています。
プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画のターゲットになる。
https://www.scrum.org/resources/scrum-guide
つまり PO は、プロダクトが将来どうなっている状態が良いのか？を考えて、スクラムチームに伝える役割ということになります。
続きを読む
スクラムチーム（Scrum Team）の開発者（Developers）は、インクリメント（Increment）を開発します。開発者がスプリントごとに作成するものがインクリメントです。スプリントごとに、前のスプリントで作成したものに追加していくことから「インクリメント＝増分」と呼ぶのですね。
Scrum.org のスクラムガイドによると、開発者について次のように書かれています。
各スプリントにおいて、利⽤可能なインクリメントのあらゆる側⾯を作成することを確約する。
https://www.scrum.org/resources/scrum-guide
このシンプルな説明文の１行だけでも、かなり重要なポイントがあります。
スクラムがなんとなくうまくいかない時や、スクラム・アジャイルに対する誤解が大きい時には、この部分のイメージがうまくできていないのかもしれません。
続きを読む
スクラムチーム（Scrum Team）は機能横断型（cross-functional）で自己管理型（self-managing）です。
Scrum.org のスクラムガイドによると、スクラムチームについて次のように書かれています。
スクラムチーム内には、サブチームや階層は存在しない。
スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えている。
https://www.scrum.org/resources/scrum-guide
また、⾃⼰管理型であり、誰が何を、いつ、どのように⾏うかをスクラムチーム内で決定する。
スクラムチームが機能横断的でなければならないというのは、とても分かりやすい話です。必要な全てのスキルを全員が持っていなければならない、というわけではないのですが、必要なスキルを少なくともチームの誰か持っていなければ、さすがに開発することができません。
一方で、スクラムチームが自己管理型であるというのは、実はなかなかイメージがしづらいように思います。
続きを読む
スクラムチーム（Scrum Team）は、プロダクトオーナー（PO）とスクラムマスター（Scrum Master）がそれぞれ1名ずつと、数名の開発者（Developers）からなる小さなチームです。
Scrum.org のスクラムガイドによると、スクラムチームについて次のように書かれています。
スクラムの基本単位は、スクラムチームという⼩さなチームである。
https://www.scrum.org/resources/scrum-guide
スクラムチームは、スクラムマスター1 ⼈、プロダクトオーナー1 ⼈、複数⼈の開発者で構成される。
これは、⼀度にひとつの⽬的（プロダクトゴール）に集中している専⾨家が集まった単位である。
はじめてスクラムをやってみるときには、まずここが難しいですよね。
続きを読む
Scrum での「よくある勘違い」として、PBI（プロダクトバックログ / スプリントバックログ）をScrum チームのメンバーで分担してしまうというのがあります。
ウォーターフォールでの慣習・考え方では特に問題がないことのように思うかもしれませんが、Scrum ではこれはうまくいかないことが多いです。
続きを読む
Scrum によくある誤解として「アジャイルは計画しないんでしょ？」「柔軟にやるって言って、計画しないから予定通りに何にも作れないじゃん」というのがあります。
自分は、Scrum を説明するときに「よくある誤解でそう言われるのですが」と先手を打って、そんなことはないというのを説明するので、最近は直接言われたことはないのですが、他の人からは、いまだにそれを理由に「アジャイルは信用できないからやらない・やりたくない」という話があると聞きます。
続きを読む
Scrum のスプリント計画での「よくある勘違い」として、最初に全 Task を各メンバーに振ってしまうというのがあります。
ウォーターフォールでの慣習・考え方では当然のことのように思うかもしれませんが、これはうまくいかないことが多いです。
続きを読む
よく「アジャイルはどんなプロジェクトに向いているの？」という質問を受けます。以前は「計画通りに進められるプロジェクトなら、ウォーターフォールの方が向いていますよ」と説明していましたが、どうも伝わっていない感じがしていました。また、向いていない場合に「ウォーターフォールの方がいいですよ」と言うと、怪訝な顔（リモートワークだと「声」でしょうか）をされたり、アジャイルが向いていないプロジェクトがあるのか？と驚かれることがよくありました。
ずっと「どう説明するのが伝わるかな？」と色々考えて試していたのですが、昨年（2022年）は「持続的イノベーションにはウォーターフォール、破壊的イノベーションにはアジャイルが向いていますよ」という説明をしてみました。
この説明が今までで一番よく伝わったように思います。
続きを読む