よわよわプロダクトバックログアイテムで悩むプロダクト開発チームに向けて、顧客からのインプットを太くすることで、つよつよプロダクトバックログを作り出すための仕組みと構造を解説します。 発表者 https://twitter.com/_N_A_ https://note.com/mryy 関…
★ はGitHubによって作られるものです。 以降、ビュー名はアルファベットで表記します。 New Item Product Backlog Item (PBI)候補の新アイテム一覧を表示します。新アイテムはリファインメントの度に確認され、Product Backlogへ移るため、本ビューは空が基本の状態となります。 クエリ no:size -ready:"Drop" Product Backlog PBIの一覧を表示します。優先順位順に並んでおり、プロダクトオーナーの合意の下で並び替えを行うことができます。 クエリ is:open -no:size -ready:"Drop" Sprint Backlog 今スプリントの対象となっているPBIとその進行状況を表示します。 クエリ sprint:this レーン概要 statusカラムの値ごとに整理されます。 TODO 進行中ではないアイテ
スクラムガイド2020には以下のように記述されています。 1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。 プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。 これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。 多くの場合、属性は作業領域によって異なる。 最初の文が意味するところは、以下のとおりです。 スプリントで選択するプロダクトバックログアイテムは1スプリント内で完成する大きさになっていなければいけない1スプリントに収まるサイズになっていれば、スプリントプランニングで選択の準備ができていると言える選択のための準備は、通常リファインメントの活動のなかで行うリファ
こんにちは、角田です。 今回はスクラムでの失敗談です。 PBIへ取り掛かるタイミング みなさんは、プロダクトバックログアイテム(PBI)へ取り掛かるタイミングはいつでしょうか?DROBEでは以前は、 スプリントバックログへ移し、スプリントが始まったら でした。一見正しそうなのですが、肝心なことを見落としていたため、効率的にデリバリーできない状態になっていました。 遅かった影響範囲調査 というのも、スプリントバックログへ移しスプリントが始まった後で、影響範囲の調査や該当箇所の洗い出しをしていました。この影響範囲調査や該当箇所の洗い出しにより、スプリント内での作業時間が圧迫された結果、非効率になっていました。 ディスカバリー不足だった この時のPBIは、ほぼ『やることリスト』化していたのが大きな原因ではないかと思っています。PBIを作る際に、開発チームとPBI作成者とのコミュニケーションが不足
みなさんこんにちは。@ryuzeeです。 プロダクトバックログリファインメントのやり方について立て続けに聞かれることがあったのでまとめておきます。長文ですが参考になれば幸いです。 まずはスクラムガイド2020を確認しておきましょう。該当する箇所は3箇所です。 スプリントでの説明(9ページ) スプリントでは、(中略) プロダクトバックログを必要に応じてリファインメントする。 スプリントプランニングのトピック2での説明(10ページ) 開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを選択し、今回のスプリントに含める。 スクラムチームは、このプロセスの中でプロダクトバックログアイテムのリファインメントをする場合がある。 それによって、チームの理解と自信が高まる。 プロダクトバックログでの説明(13ページ) 1スプリント内でスクラムチームが完成できるプロダクトバッ
はじめに こんにちは。カケハシでPatient Engagementという新規事業に関わるプロダクトマネジャー(以降PdM)を担当している渡部と申します。現在はこれらの事業を加速させるために、いわゆる0→1フェイズ、かつ、SoE(System of Engagement)の側面が強いプロダクト・サービスの企画開発をしております。 カケハシではスクラムでのアジャイル開発が共通して採用されていますが、前述のプロダクト特性上、お客様ごとに置かれている状況も考え方も異なる状況下であるべきを模索し続ける必要があります。いわゆるVUCAそのものなサービス開発に日々取り組んでいます。 そんな不確実性が高い状況下で仮説検証サイクルを最速にできるよう、我々のチームのスプリントのタイムボックスは1週間、スクラムチームの成果物の一つであるインクリメントを生み出していくという活動をしています。このとき、日々プロダ
ABEJA でスクラムマスターをしている小川です 最近、私のチームのプロダクトオーナーとプロダクトバックログの管理やチーム内外との透明性の持たせ方について話をしていました。 改めて基本的な「プロダクトバックログの役割」について考えさせられました。 「プロダクトバックログが荒れてきた...」「もっとシンプルに活用したい...」といったお悩みがありましたら、少し基本に帰ってみるとよさそうだと思いましたので、こちらの記事がそのきっかけになれば幸いです! まずは言葉の定義から、、、 プロダクトバックログとは、プロダクトバックログアイテム(PBI)を並べたものです。 プロダクトバックログについて、スクラムガイドではこのような説明があります スクラムガイドから抜粋 プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの⼀覧である。これは、スクラムチームが⾏う作業の唯⼀の情報
この記事は何 以前Qiitaで以下のようなスクラムに関しての記事を投稿しました。 これらの記事では「チームとしてゴールを達成するため」のTipsについて紹介してきました。 しかし、そもそもスプリントゴールがなんなのかを理解していないと、これらのTipsを実践することは難しいです。 この記事ではスプリントゴールとはどういうもので、どのように設定すると良いかを説明します。 スプリントゴールのよくある勘違い スクラムを実施しているチームの中で、たまに「ゴールは特に設定していない」という方がいらっしゃいます。 ゴールを設定しない理由は以下のとおりです。 このスプリントでやりたいことはスプリントバックログとして残してあるからゴールを設定する必要がない 結局スプリントゴールを設定しても、やることが「スプリントバックログを空にする」になってしまうから これらの主張は一見正しいように見えますが、スプリント
BOXIL SaaSの開発チームについて Notionでプロダクトバックログの管理をやってみた結果 尋常じゃない量のプロパティ Sprint番号 PointとPlanning Point 親タスクとサブタスク ドキュメントのリレーション 実装の効果 所感 メリット ドキュメントツールとタスク管理ツールが同じだって?! 自由性 新しい機能が増えていくのが楽しい デメリット あくまでドキュメントツール 多機能すぎる 自由すぎる まとめ こんにちは!! BOXIL SaaSのエンジニア兼テックブログチーム平社員をしているブラーバです。今週は弊社テックブログチームのスクラム月間(勝手に言ってる)ということで、プロダクトバックログの管理をNotionで行っているお話をしようかと思います。 もともと、弊社では社内のドキュメントを他のドキュメントツールで管理していましたが、以下のような理由でNotion
« Back to Glossary Indexプロダクトバックログ(PBL)とは 機能や技術的改善要素など、開発チームが対応すべきすべての項目を優先順位をつけて一覧にしたものです。 これらの項目はプロダクトバックログアイテムとして管理されます。プロダクトバックログアイテムには要件、機能、受入条件、優先順位の情報が含まれます。 プロダクトバックログアイテムはユーザーストーリーを元に作成されます。ユーザーストーリーとプロダクトバックログアイテムは「1:n」の関係になります。すべてのユーザーストーリーをバックログ化する必要はありませんが、バックログの総量を把握しておくことでリリースの見通しは立てやすくなります。 プロダクトバックログは、ステークホルダー全員が参照し、現在のプロジェクトの状況が把握できるようにします。 誰でもプロダクトバックログアイテムを追加することはできますが、優先順位は最終的
短編映画『バックログ』の感想 日本でも大きな話題を集めている性加害問題をストレートに描いた『バックログ』は性犯罪について深く考えさせられる作品です。 事実に基づいて描かれたストーリーは、目を逸らしたくなるような真実をつきつけてきます。 『バックログ』で取り上げられているレイプキットの存在を知っていますか? レイプキットは性加害にあったとき、病院で医療従事者が使用するアイテムのパッケージです。 犯人を特定し有罪判決を獲得した事例もあるようですが、作中でマロリーが言っていた通り、多くのレイプキットが未検査のまま残ってしまっています。 作品の最後には連邦政府から検査のために年間151億円もの資金提供が承認されているようですが、この資金のほとんどが使われていないというのは驚きです。 資金だけではなく、人手が足らないなどの問題もあるのかもしれませんが、ここまで放置されてしまうのはどうにかできないのか
プラクティス名(別名) プロダクトバックログアイテム分割(ユーザーストーリー分割、縦切り、Vertical Slice) プラクティスの目的・狙い 大きすぎるPBIをスプリント投入できるサイズに切り分ける 1つのユーザストーリーに含まれる優先度の高い機能と低い機能を切り分ける どんな時に使うか PBIがボリューム的に1スプリントの中でつくり切れない時 スプリントの工数にまだ少し余裕があるが、次のPBIを拾うと溢れてしまう時 MVPのサイズをできるだけ小さくしたい時 実施手順 分割対象のPBIについて、より詳細なフィーチャー単位で切り分ける(=縦切り) ※切り分けに困る場合は、ストーリーを具体化すると切れ目を見つけやすくなる 切り分けた結果、PBIに依存関係が生じてしまうこともあるが、分割を優先する ストーリーポイントを再度見積もる(その合計は元の値と一致するとは限らない) 優先順位を見直す
Warning: Undefined array key "footer-widget-center-2" in /home/nagasawa/servantworks.co.jp/public_html/wp-content/themes/emanon-premium/inc/template-cache.php on line 190 Warning: Undefined array key "footer_widget_copyright" in /home/nagasawa/servantworks.co.jp/public_html/wp-content/themes/emanon-premium/inc/template-cache.php on line 213 Professional Scrum Product Owner™ 認定研修(試験付き) (2024年3月28日
この記事は、NFLaboratories Advent Calendar 2022 5日目の記事です。 こんにちは。ソリューション事業部 セキュリティソリューション担当の香川です。 普段はスクラムマスターおよび開発者としてスクラムの手法を用いた開発を行っています。 スクラムの作成物の1つにスプリントバックログがあります。スプリントバックログは開発者が作成するスプリントの作業の計画で、一般的には各PBIをタスクに分解して作成されることが多いと思います。以下の図はその例になります。 私のチームではGitLabのIssue Boardを使ってタスク管理をしています。しかし、GitLabではタスクがどのPBIに紐づいているのかを表現しづらいという課題がありました。そのため、PBIをDoneにするためにどんな作業が残っているのか?スプリントがどのようなステータスなのか?が分かりづらく、作業の進め方に
こんにちは、エンジニアのタカです。 普段はスクラムマスターや開発者としてプロダクトの開発に関わっています。 チームではスクラム開発を導入しており、今回はNotionでのバックログ管理の話をしたいと思います。 当初のバックログ管理方法 自分が所属するチームでは、バックログは、当初Miroで原案を作ったのちGitHub + ZenHubにて作成し管理していました。 バックログに加えバグや要望も同様にGitHub + ZenHubで管理していましたが、ナレッジやドキュメントはNotionに作成しており、下記のような課題を持っていました。 バックログ、要望、バグが混ざって見にくい バックログとドキュメントを参照するのに複数のサービスを行き来するのは手間がかかる Sprint単位のバックログや状態が把握しにくい 現在のバックログ管理方法 これらの課題を解決するため、バックログ等をすべてNotionに
こんにちは、Eight事業の開発責任者の大熊です。 Eight事業では、ビジネスパーソン向けの名刺アプリ「Eight」を中心にそのプラットフォーム上でさまざまなサービスを展開しています。最近ではビジネスイベントとITを掛け合わせた新しいイベント体験を創出するという挑戦に取り組んでいます。開発組織が対峙するビジネス状況はBtoC、BtoB、あるいはモバイルアプリ、ビジネスイベントとバラエティ豊かです。 そんなEight事業ですが、事業状況に合わせてバックログへの向き合い方も都度変化してきました。この記事では、過去の取り組みを通じてうまくいったこと、いかなかったこと含めてその変遷をまとめ、今どうしているかをお伝えします。 ※「バックログ」はビジネスやプロダクトで実現したいことリスト、「アイテム」は具体的な開発対象とここでは定義しています。 ビジネスごとのチームアサイン ビジネスごとにバックログ
スクラムガイド2020には以下のように記述されています。 1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。 プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。 これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。 多くの場合、属性は作業領域によって異なる。 最初の文が意味するところは、以下のとおりです。 スプリントで選択するプロダクトバックログアイテムは1スプリント内で完成する大きさになっていなければいけない 1スプリントに収まるサイズになっていれば、スプリントプランニングで選択の準備ができていると言える 選択のための準備は、通常リファインメントの活動のなかで行う
バックログなり、施策なりを具体化するところで、その中身があまりにタスク気味になってしまっているのは、よくあることかもしれない。バックログ、施策には粒度感があり、考えるところから実行するまでタスクレベルだったりすると、粒度が細かすぎる、手段しか見えておらず目的が不明、それゆえに他のアイデアが出にくい、いつものタスクマネジメントと同じになる、といったぐんにゃり感が高まってくる。 「アジャイルって言ったって、結局タスクマネジメントじゃん(いつもとそんな変わんないじゃん、むしろミーティングが多くてオーバーヘッド高すぎじゃん?)」という声が早晩あがってくる。 このつぶつぶの粒度感というのはとっても大事。「アジャイルはじめようぜ」の最初を乗り越えた後以降は、粒感との戦いが山場になっていく。構造化の整理が必要なのだ。 構造化の先頭をやるべきこと(ToDo)にしてしまうと、それ以降WHYに立ちかえるのは難
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く