どこでもプロジェクト管理バックログ
有料契約件数14,000件以上 サービス継続率98.8% ※2023年12月末時点。サービス継続率は各前月の有料契約総数に占める解約数を引いた割合。 Backlogでプロジェクト・タスク管理のお悩みを解決 タスク漏れやスケジュール遅延が発生する... 現場の状況を把握できず、進捗確認の会議ばかり... 業務改善ツールを導入しても一部のメンバーしか使ってくれない... メンバーが増えるとツールの費用が増えて大変... 担当者や期日が明確になることで、タスク漏れやスケジュール遅延を防ぐ 誰がどのタスクを進めているかを分かりやすく見える化。「あの案件どうなってたっけ？」を防いで業務が円滑に進む手助けをします。
Jira SoftwareやTrelloなどを中心としたPMが経験してきたプロダクト管理ツールの失敗や改善を語る「本当に使いこなせてる？プロダクト管理ツールの失敗&改善PMトーク【開発PM勉強会 vol.20】」。ここで株式会社ビズリーチの菊池氏が登壇。ドキュメント管理とプロダクトバックログの失敗から学ぶツール運用のコツについて紹介します。 菊池氏の自己紹介 菊池信太郎氏（以下、菊池）：ビズリーチの菊池から、10分枠で話をします。今日のテーマは「失敗から学ぶドキュメントとチケット運用のコツ」ということで、今まで経験したところで「こういうアンチパターンがあったよ」「こういう改善をしたよ」というようなところをお話しできればと思っています。 自己紹介を軽くすると、（私は）2018年からビズリーチで働いています。ビズリーチサービスを作っていて、プラットフォーム開発部の部長をしています。また、201
「バックログに入らないタスクを可視化する仕組み」という話を技術勉強会でしました - Hatena Developer Blog
こんにちは。アプリケーションエンジニアの id:daiksy です。 はてなでは毎週木曜日に技術勉強会を開催しています。 参考: 寿司と勉強会とエンジニア - Hatena Developer Blog 先週、当番が回ってきたので、「バックログに入らないタスクを可視化する仕組み」というトークをしました。 speakerdeck.com 詳細はスライドを見ていただくとして、この発表で定義された「税」などの用語が、さっそく社内でのコミュニケーションでも使われだして、エンジニア同士で、ある概念について共通の認識を持つためにもこういった場は効果があるな、と実感しました。 はてなでは、アプリケーションを構築する技術だけではなく、プロジェクトマネジメントやチームビルディングの知見などもこうして技術勉強会で共有されています。
【資料公開】プロダクトバックログ Deep Dive
みなさんこんにちは。@ryuzeeです。 昨年12月に新刊『チームトポロジー』が発売になったのでぜひよろしくお願いします。 今年もスクラム実践者の祭典であるRegional Scrum Gathering Tokyoが、2022年1月5日〜7日までの3日間開催されました。 このイベントで「プロダクトバックログ Deep Dive」というタイトルで発表しましたので、資料を公開します。 スクラムガイドでも、プロダクトバックログという単語の登場回数は非常に多く、それだけ重要だということが分かります。 一方で網羅的にまとまっている資料が日本語ではあまり存在しなさそうなので、今回用意してみました。 内容については、過去にこのブログで説明している箇所も多数ありますが、1箇所にまとめたことに意義があるということでご了承ください。 みなさんのお役に立てば幸いです。 内容に関するご意見やフィードバックは、T
プロダクトバックログDeep Dive。スクラムのプロダクトバックログをどう作成し、手入れし、スプリントに投入するべきか（前編）。Regional Scrum Gathering Tokyo 2022
プロダクトバックログDeep Dive。スクラムのプロダクトバックログをどう作成し、手入れし、スプリントに投入するべきか（前編）。Regional Scrum Gathering Tokyo 2022 代表的なアジャイル開発手法の1つであるスクラムを構成する要素として「プロダクトバックログ」はもっとも重要なものの1つです。 プロダクトバックログは、プロダクトが目指す「プロダクトゴール」を含み、「スクラムチームが行う作業の唯一の情報源」とされています。 このプロダクトバックログとはどのようなもので、どう作成し、手入れをし、どのようにスプリントへ投入していくべきなのかを詳しく解説した、株式会社アトラクタ 吉羽龍太郎氏のセッション「プロダクトバックログDeep Dive」が、1月5日から7日まで行われたイベント「Regional Scrum Gathering Tokyo 2022」で行われまし
プロダクトバックログアイテムの分割方法
みなさんこんにちは。@ryuzeeです。 プロダクトバックログアイテムは、複数スプリントにまたがって1つのものに着手することはありません。 必ず、1スプリントで完成できる大きさになっている必要があります。 これは、複数にまたがってしまうと変化に柔軟に対応できなくなること、成果の量の把握が難しくなること、大きいものを扱うのはそもそも難しいことなどが理由です。 そのため、プロダクトバックログアイテムがプロダクトバックログのなかで上位になっていくにつれて、リファインメントなどを活用しながら、適切なサイズに分割していきます。 最初の段階から細かく分割してしまうと、変化に対応しにくくなったり、数が多くなりすぎて管理しきれなくなったりするので避け、着手が近づいてきたらジャスト・イン・タイムで分割していくのがポイントです。 こうすることで、チームの成長にあわせてプロダクトバックログアイテムのサイズを変え
顧客からのちょろちょろインプットを脱却 顧客からのめちゃ太いインプットを通して何を選んでもアウトカムを生み出すプロダクトバックログを実現する/Break free from narrow customer input 2024
よわよわプロダクトバックログアイテムで悩むプロダクト開発チームに向けて、顧客からのインプットを太くすることで、つよつよプロダクトバックログを作り出すための仕組みと構造を解説します。 発表者 https://twitter.com/_N_A_ https://note.com/mryy 関連スライド ■もっとプロダクト組織の問題を学ぶ 「プロダクトマネージャーがプロダクトマネジメントを失敗させる!?」大企業病の罠を乗り越え若々しいチームを実現するぞ https://speakerdeck.com/moriyuya/traps-of-optimization-in-product-management-2024 「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法 https://speakerdeck.com/moriyuya/p
みなさんこんにちは。@ryuzeeです。 プロダクトバックログはスクラムにおける生命線の1つです。 プロダクトバックログが良くないとプロダクトの価値がでなかったり、そもそもスクラムチームとして安定したデリバリーを行えません。 プロダクトバックログでよく起こる問題プロダクトバックログを管理する上でみなさんがよく知っているのは、並び替えをする、という点ですが、これだけではまったく不十分です。 単に並び替えだけをしたプロダクトバックログで、スプリントを始めてしまうと以下のようなことが起こります。 選択したプロダクトバックログアイテムの中身に対してプロダクトオーナーと開発チームの理解が違ってしまうそのためスプリントを開始した後に頻繁にプロダクトオーナーと会話をする必要が出てきてしまい、場合によっては本来の要求が別のものであることが判明するもしくは色々会話をしていたら、当初の想定以上に規模が大きいこ
スプリントでのプロダクトバックログ項目着手の方法
みなさんこんにちは。@ryuzeeです。 スプリント中に対象のプロダクトバックログアイテムにどのように取り組んでいくか、というのは意外とよく質問を受けるので、ここで整理しておきたいと思います。 話を分かりやすくするために、スクラムボードを見ながら考えていきます。 アンチパターン1：プロダクトバックログアイテムごとに担当を決める まず最初に避けるべきなのは、プロダクトバックログアイテム単位で担当を決めてしまうやり方です。スクラムでは誰かが開発チームのメンバーに対して作業を割り当てることはしませんが、割り当てているかどうかに関係なく、開発チームのメンバーが「特定のプロダクトバックログアイテムにサインアップして、そこを全部担当する」というのも避けるべきです。 このやり方をした場合には、次のような問題が発生します。 開発チームのメンバーは自分がサインアップしたプロダクトバックログアイテムの完成ばか
みなさんこんにちは。@ryuzeeです。 プロダクトバックログ項目からタスクにうまく分割できないので、あればそのコツが知りたいと@riskriskさんからリクエストを頂いたので解説したいと思います。 まずは以下の図を見てください。 これはスクラムにおいて、プロダクトバックログからスプリントバックログへの流れを会議体とともに示したものです（パワーポイント版はこちら）。 実はほぼこの中に全て答えがあります。 まずプロダクトバックログ項目（ストーリーなど）からタスクにうまく落とせない場合は、以下のようなことが原因として考えられます。 そもそもなんのためにそのプロダクトバックログ項目があるのか分からないプロダクトバックログ項目の内容が曖昧または抽象的すぎて、作るべきものが分からない。または人によって著しく成果物のイメージが異なるプロダクトバックログ項目に受け入れ条件がないため、何ができたらそのバッ
どんな開発プロセスでも製品やサービスを作るときは何からの形で要件をまとめると思います。KRAYが採用しているアジャイルソフトウェア開発フレームワーク『スクラム』では、製品やサービスの要件リストをプロダクトバックログと呼びます。実はこのプロダクトバックログ、その書き方や運用の仕方で開発のモチベーションが大きく違ってきます。書き方一つで、開発チームにとってもプロダクトオーナーにとっても見るのが楽しみな資料になりうるのです。 今回は、見るのが楽しみになる魅力的なプロダクトバックログを作るコツについてお話しします。 プロダクトオーナーから見たプロダクトバックログ 最初にプロダクトバックログのライフサイクルについて簡単におさらいします。 開発が決まったら、プロダクトオーナーは製品のビジョンを実現するために必要な機能などをユーザーストーリーと呼ばれる文章で表現し、プロダクトバックログに追加していきます
Ryutaro YOSHIBA @ryuzee 「なぜスクラムガイドではプロダクトバックログリファインメントをイベントとしていないのですか？」という質問を頂いたので、ぼくの見解をつらつらと。 まずプロダクトバックログでやらないといけないのは、最新の状態に保つこと、直近のスプリントで着手しそうなものの準備ができてること 2018-06-16 07:05:55 Ryutaro YOSHIBA @ryuzee (続) プロダクトバックログがこの状態になっていればOKで、いつもちょっとだけ先のことを見通しながら手入れをしておけばよい。大事なのは「プロダクトバックログの状態」ってことになる。 じゃあ、いつ手入れするのか、だけど「思いついた時にやる」だと最初はできない 2018-06-16 07:09:41 Ryutaro YOSHIBA @ryuzee (続) なのでぼくの場合は「スプリントの中間く
GitHub Projectsを使った（プロダクト/ スプリント）バックログ管理 #スクラム | DevelopersIO
★ は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 進行中ではないアイテ
「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。 今回の内容 ●課題： 予定外の仕事が入ってタスクをこなし切れず、残業ばかりである ●スクラムのプラクティス 「スプリントバックログ」を作り、自分の作業を把握する ポイントは、「サイズを見積もる、優先順位、完了の条件」 「スクラム」は、ソフトウェア開発のマネジメント・フレームワークの1つで、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化した枠組みです。 本連載は「まずはちょっとしたスクラム」をモットーに、チームとしての仕事の進め方を改善するスクラムの知識を簡潔にお伝えします。「開発現場でスクラムやアジャイル開発を使ったことがないんだけど……」というエンジニアでも大丈夫。多くの現場で使え
みなさんこんにちは。@ryuzeeです。 スクラム道FullBoostで出ていた質問と議論で若干うずうずするところがあったので、好き勝手に答えてみます。 なお、回答はあくまでコーチとしての勝手な見解であり、全てのコンテキストに有効な絶対解では決してありません。 そもそも自分達のおかれたコンテキストを踏まえた上で、どうやったらもっとうまくいくのかを考え続け改善していけばよいのです。 「パーキンソンの法則」を「ストーリーポイント」で防ぐ事はできるのか？パーキンソンの法則とは、「ある資源に対する需要は、その資源が入手可能な量まで膨張する」という法則で、開発にあてはめれば、確保した時間は、それを使い潰すまでつ使ってしまう、ということになる。 この症状をストーリーポイントによって解消できるか、という質問に対しては、答えはNoだ。 それは以下の理由だ。 ストーリーポイントは単なるポイントであり、なんら
プロダクトバックログについて海外の例も踏まえ考えたこと
Agile経験がほとんど無いチームにScrum＋XPの開発方法を教えながら開発しているのだが、 プロダクトバックログと見積もりポーカーのあたりでメンバーがもやっとしていたようなので 自分自身の整理も兼ねてメモ。 事例検証 まず以下は海外サイト等で公開されているプロダクトバックログのサンプルをいくつか見てみよう。 SimpleProductBacklog http://agilesoftwaredevelopment.com/scrum/simple-product-backlog 気になるところ Sprintに入る前に「#1 CI環境を構築する」「#4 Webサーバを構築する」とかあるけど、顧客から見るとどうかな？これはSprint0のタスクであるような気がする。 このリストはフィーチャーなのかストーリなのかが分かりにくい。Sprint1の項目はフィーチャー。Sprint2の内容はストーリ
プロダクトバックログとスプリントバックログの見積もり
みなさんこんにちは。@ryuzeeです。 以前お客様先でスクラムのトレーニングを実施した際に、プロダクトバックログアイテムとタスクの見積りについて質問をいただきました。 見積りについてはもっとも質問をいただく項目の1つでもあるので、ここでスクラムにおける見積りについて書いておくことにします。 プロダクトバックログアイテムの見積りまずはプロダクトバックログアイテムの見積りについて考えてみましょう。 なぜプロダクトバックログアイテムを見積もるのか？なぜプロダクトバックログを見積もるかといえば以下の理由です。 そのプロダクトの全体を把握する。全体のサイズが分からないと現在の進捗が把握できません。もちろん全てのプロダクトバックログアイテムを絶対に作るかといえばそうではなく、途中でプロダクトバックログアイテムが追加されたり削除されたりしますが、それでも全体の概要を把握しようとすることには意味がありま
みなさんこんにちは。@ryuzeeです。 ここに新しくECサイトを作ろうとしているアジャイル開発チームが2つあったとします。期間はどちらも同じです。 1つめのサイトAは、商品を探すための機能として、商品名による検索、価格による検索、発売元メーカーによる検索、評価順による検索、あいまい検索などさまざまな検索機能を用意しましたが、もう1つのサイトBには商品名による検索しかありませんでした。 さてどちらが良いでしょうか。 答えは当然ですが、「これだけでは分からない」になります。 ちょっと条件を追加しましょう。 サイトAは、いろいろな検索方法で商品を探せますが、残念ながら決済機能の開発が間に合わなかったので、まだ商品の購入はできません。一方で、サイトBはクレジットカード（JCBとVISAだけ）は決済できるようになっています。 さて、こうなるとどちらが良いでしょうか。 答えは明確にサイトBになります
プロダクトバックログアイテムはいつ見積もればいいですか？
スクラムガイド2020には以下のように記述されています。 1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。 プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。 これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。 多くの場合、属性は作業領域によって異なる。 最初の文が意味するところは、以下のとおりです。 スプリントで選択するプロダクトバックログアイテムは1スプリント内で完成する大きさになっていなければいけない1スプリントに収まるサイズになっていれば、スプリントプランニングで選択の準備ができていると言える選択のための準備は、通常リファインメントの活動のなかで行うリファ
ANA recruits are given Military Operational Urban Training アジャイル開発系の勉強会に参加したり発表したりするようになって、いろんな方から社内に広げていく方法について相談されるようになりました。 一概に「これ！」という答えはないのですが、今の自分の考えとして「エンタープライズバックログ」という作戦を今日はをご紹介。 例えば小規模プロジェクトで成功事例を作り横展開する作戦 例えば、広めるための作戦として「アジャイル開発導入事例」で「小さなプロジェクトで成功例を作り、横展開やスケールにつなげる」という作戦をたまに聞きます。この方法は本当にスケールするんでしょうか？ なぜなら、チームやグループといった単位で抱える課題は様々で、優先順位も場所によって違います。扱う業務も違えばメンバーも違う。実際に、社内でアジャイルコーチ/トレーナーのような
こんにちは、角田です。 今回はスクラムでの失敗談です。 PBIへ取り掛かるタイミング みなさんは、プロダクトバックログアイテム（PBI）へ取り掛かるタイミングはいつでしょうか？DROBEでは以前は、 スプリントバックログへ移し、スプリントが始まったら でした。一見正しそうなのですが、肝心なことを見落としていたため、効率的にデリバリーできない状態になっていました。 遅かった影響範囲調査 というのも、スプリントバックログへ移しスプリントが始まった後で、影響範囲の調査や該当箇所の洗い出しをしていました。この影響範囲調査や該当箇所の洗い出しにより、スプリント内での作業時間が圧迫された結果、非効率になっていました。 ディスカバリー不足だった この時のPBIは、ほぼ『やることリスト』化していたのが大きな原因ではないかと思っています。PBIを作る際に、開発チームとPBI作成者とのコミュニケーションが不足
プロダクトバックログアイテムの粒度の考え方
みなさんこんにちは。@ryuzeeです。 今日はTwitter経由で頂いた質問に回答したいと思います。 質問は以下になります。 プロダクトバックログアイテムの粒度について教えてください。 ECサイトだとして、「購入者が販売商品を購入できる」というユースケースの場合、PBIに入れるユーザーストーリーとしては、「購入したい商品を検索し商品を確認できる」「購入したい商品を買い物カゴに入れる」「買い物カゴの商品を購入する」のような粒度で良いのでしょうか？ それとももっと細かいレベルまで分割すべきでしょうか？「購入者は購入したい商品の値段を確認できる」とか「購入者は購入したい商品の名称を確認できる」みたいなレベル感でしょうか？ 複数画面をまたがり使用するデータベーステーブルはいつ決めてどうストーリーポイントを決めるのでしょうか？ それでは考えていきましょう。 1つのプロダクトバックログアイテムを複数
バックログには背骨が欠けている
垂直スケーラビリティと効果的なテストによる金融取引システムのパフォーマンスと効率の最大化 Peter Lawrey氏はJavaチャンピオンであり、Chronicle SoftwareのCEOとして、開発者を鼓舞してソリューションのクラフトマンシップを高めることに情熱を注いでいる。経験豊富なソフトウェアエンジニアとして、Lawrey氏はソフトウェア開発プロセスにおけるシンプルさ、パフォーマンス、創造性、革新性を奨励することに努めている。
Jira SoftwareやTrelloなどを中心としたPMが経験してきたプロダクト管理ツールの失敗や改善を語る「本当に使いこなせてる？プロダクト管理ツールの失敗&改善PMトーク【開発PM勉強会 vol.20】」。ここで株式会社クライドのSuyama氏が登壇。「PdMのプロダクトバックログ」と「POのプロダクトバックログ」の分離をどのように行ったのかについて話します。 Suyama氏の自己紹介 Daiki Suyama氏：もともとあったタイトルと若干異なるのですが、今回は「事業とプロダクト間のインターフェース作り」というところでお話しできればと思います。 軽く自己紹介をすると、2022年4月に現在の株式会社クライドに入社して、フルサイクルエンジニアとして働いていました。2022年11月にそこに加えてDevOpsの部分やイベントの企画、新卒採用など、いろいろな業務に携わり始め、2023年4月
みなさんこんにちは。@ryuzeeです。 スクラムチームのなかで分業と平行作業が多くなっているのを見かけることがあります。 この理由の1つは、スプリントバックログの一環として作られたタスクの分解の仕方にあります。今日はこれについて見ていきたいと思います。 スプリントバックログとは？まずは復習です。 ご存じのとおり、スプリントプランニングでは、そのスプリントで達成したいスプリントゴールを検討し、スプリントゴールの達成に必要なプロダクトバックログアイテムを選択し、インクリメントを届けるための実行計画を作成します。これら3つを合わせたものをスプリントバックログと呼びます。 スプリントバックログは、開発者による開発者のためのもので、必要に応じてリアルタイムで更新していきます。 毎日のデイリースクラムで進捗を検査できる程度の粒度である必要があります。 スプリントプランニングではタスクの分解が必要なの
初期のプロダクトバックログの作り方
みなさんこんにちは。@ryuzeeです。 別のところで依頼を受けて作った文書なのですが、皆様の参考にもなるかと思いますので共有しておきます。 まずはプロダクトゴールを検討するプロダクトバックログは、プロダクトゴールの実現のために存在します。 つまりプロダクトバックログを作るには、プロダクトとして実現したいゴール、顧客に提供したい価値などをあらかじめ検討する必要があります。 リーンキャンバス、エレベーターピッチ、ユーザーインタビュー、エスノグラフィーなどのテクニックを活用しながら、プロダクトとして解決したい課題、実現したい価値やゴールを評価しますプロダクトを実際に開発するのはお金も時間もかかるので、本来この時点で仮説検証を繰り返し、ダメなアイデアを早めに捨てる必要がありますある程度いけそうなアイデアが出てきたら先に進みますスプリント開始の条件スクラムでスプリントを開始できるのは、プロダクトバ
ソフトウェア開発におけるバックログの運用には、トヨタ生産方式のかんばんの運用から学べる点が多くあります。本セッションでは、トヨタ生産方式のかんばんを具体的にご紹介し、バックログの運用方法との共通点と相違点を説明します。また、ソフトウェア開発における「在庫」とは何か、解き明かします。
Linkedinは、ビジネスロールごとのディスカッションが面白いのでおすすめです。今回見つけたのが「What software do you use to track user stories and tasks? To manage a product backlog and build sprint backlogs?」というディスカッション。「アジャイル開発に登場するユーザーストーリーやバックログをどんなツールで管理しているか？」が共有されています。 すでに３００を越える共有や議論が行われており、世界のスクラムマスターはどんなツールを使っているのか、気になったので調べてみました。 優勝したツールは・・・ 今回の優勝ツールは「Jira」でした。 Jira+Greenhopper 46票 TFS 28票 Rally Software 27票 Excel 26票 VersionOne 16
1. プロダクトバックログ Deep Dive 2022/1/6 Regional Scrum Gathering Tokyo 2022 株式会社アトラクタ 吉羽 龍太郎 (@ryuzee) 2. 自己紹介 吉羽龍太郎 / YOSHIBA RYUTARO ▸ アジャイル開発、DevOps、クラウドコンピューティング、 インフラ構築自動化、、組織改革を中心にオンサイトでの コンサルティングとトレーニングを提供。著書訳書多数 2
プロダクトバックログアイテムの優先順位の付け方
みなさんこんにちは。@ryuzeeです。 プロダクトバックログアイテムの優先順位を決めるにはいくつかの方法があります。 Backlog Prioritization Techniquesにて、いくつかのやり方が説明されていましたので抜粋・意訳にてご紹介します。 どれを使うかは、そのプロダクトが自社製品かどうか、その製品の新規性の有無、開発の体制などなど、コンテキストに依存するところがあるので、どれが一番良いというのはありません。 ただ、分かりやすいという点では、狩野モデルは良いと思っています。 MoSCoW法M 絶対必要S できれば実装すべきC 他への影響がなければ実装できるとよいW 今回は実装しないが将来に実装するかもそれぞれの要求に対してMからWまでのタグをつける。 Mは優先順位がもっとも高く、Wは最も低いということになる。 ビジネス価値に基づく判断それぞれの要求は潜在的なビジネス上の
プロダクトバックログの項目は「優先付け」するんじゃなくて「並び替える」 - capsctrldays(2011-08-02)
プロダクトバックログの項目は「優先付け」するんじゃなくて「並び替える」現在、新しい『Scrum Guide』を訳しています（現在レビュー待ち）。今回の変更で気になったのが、プロダクトバックログの項目を「優先付け（Prioritized）」するんじゃなくて、単に「並び替える（Ordered）」という点です。 詳しくは、世界の破壊者 Jim Cope による「Ordered Not Prioritized」に譲りますが、端的に言えば「優先順で並べることが、必ずしもROIや価値を最大化するわけではない」ということです。先の例を借りれば、どんなに優先度が高くてもサンタの画像は冬に表示することに価値があり、どんなに家の屋根が気になっていても最初から屋根を作れるわけはない、ということです。 プロダクトバックログは時間軸を伴う有機的な存在です。全体最適を考えて、柔軟に「並び替える」ことが成功の鍵となりま
どの色があなたのあなたのバックログ?
原文(投稿日：2010/05/02)へのリンク 最近 シドニー とウェリントン で開かれたSDC conference（ソフトウェア開発カンファレンス）でPhilippe Kruchten教授は “あなたのバックログは何色” と題する講演を行った。講演の主眼点は、システムの機能実現とともに、アジャイルプロジェクトにおける、ソフトウェアアーキテクチャ面からの重要性に焦点をあてることである。 Kruchten教授は、アジャイル手法が、YAGNI (You Ain’t Gonna Need It:あなたにそれが必要ない)やリファクタリングに焦点をあて、そして“最後の責任の伴う瞬間” が長期に渡り重要な決断を遅らせるリスクをもたらすまで判断を委ねる姿勢をとった。 どのプロジェクトにおいても 進行中の業務に対して状況を設定するには、主要な一連の決断を早期に決定しておく必要がある。 –これらの
プロダクトバックログは継続的に更新される生きたドキュメントである。 プロダクトバックログには、全ての機能要求、非機能要求を含むすべての要求を含んでいる。 なぜプロダクトバックログのリファインメントを行うのかプロダクトバックログリファインメントは極めて重要だ。以下のようなことに役立つ。 開発チームとプロダクトオーナーが大きなプロダクトバックログアイテムを小さいものに分割するのに役立つ。それによって個々のプロダクトバックログアイテムのスコープについてより理解が共有される。開発チームとプロダクトオーナーは長くて息切れするようなスプリントプランニングを避けることができる。それによって時間のムダを防げる。プロダクトオーナーによって追加された新たなプロダクトバックログアイテムや既存のプロダクトバックログアイテムをより小さいものに分割する。開発チームはより簡単にプロダクトバックログアイテムの見積りができ
バックログ・グルーミング: 誰が、いつ、どのように行うか
Rustが再評価される：エコシステムの現状と落とし穴 In this article, we share findings and insights about the Rust community and ecosystem and elaborate on the peculiarities and pitfalls of starting new projects with Rust or migrating to Rust from othe...
チームが今どこにいて、これからどこに行くのかという感覚をチームに与えるものです。バックログは、その価値の分だけ真剣に受け止めるべきです。 Ron Jeffries氏: おそらく多くの目的があります。私が示したいのは、異なる価値がある以下の2つです。 1. いつかやろうと思うことを追跡するため。 2. 他の人たちに要求の状態を伝えるため。 Jeff Patton氏: 私にとって、バックログは2つの目的を持ちます。1番目は、構築している製品の「形」について、その製品が何であり、どうなるのか、そして、誰のためのものかといったことを理解する役に立ちます。「大きなストーリー」として高いレベルでその形を理解します。これは、Alistair氏がNauer氏による「理論構築」を引用したことをDave氏が述べたことと共鳴します。これこそが、私たちがしなければならないことです。私は、理論を伝えるための「ストー
みなさんこんにちは。@ryuzeeです。 プロダクトオーナーやプロダクトバックログに関してよく頂く質問についてまとめました。 スクラムではフレームワークとして定義されているものをどのように実装するかはスクラムチームに任されているので以下の僕の回答はあくまで僕個人の見解です。 プロダクトバックログにはバグは乗せないのか？A. スプリントの作業の一環として行ったテストで発覚したバグは載せません。 それは単にスプリント内で解決すべき項目であり、バグが残っている状態ではプロダクトバックログアイテムが完了とならないだけだからです。 既にリリースされているもののバグであればプロダクトバックログに載せて、対応の順位付けをします。 ただしプロダクトバックログに載せるまでもなく、すぐ修正が終わるようなものはとっとと終わらせてムダに追跡をしない方がよい場合も多いでしょう。 スプリントプランニング時にデザインが
たまにはLinuxネタを。 Listenバックログは、伝統的なUNIXの実装だと、SYN_RCVDとESTABLISHEDの両方のソケット数を数えますが、LinuxのそれはESTABLISHEDな状態の数だけを数えるようになっています(manを見よ)。 これは何でかというと、いわゆるSYN Flooding攻撃への対応として、Linuxはsyncookieを実装したことの副作用なのだと思います。syncookieを実装していると、SYNに対してSYN_ACK(COOKIE)を返すコストがほぼゼロ（メモリコストとしては）になるので、来たSYNにすべてSYN+ACKを返すことが可能です。 したがって、SYN_RCVDの数は数えても意味がなくなったので、それはListenバックログの数としてカウントしないようにした、ということのようです（厳密に言うと、tcp_max_syn_backlog個まで
プロダクトバックログリファインメントはいつ何をするのか
みなさんこんにちは。@ryuzeeです。 プロダクトバックログリファインメントのやり方について立て続けに聞かれることがあったのでまとめておきます。長文ですが参考になれば幸いです。 まずはスクラムガイド2020を確認しておきましょう。該当する箇所は3箇所です。 スプリントでの説明（9ページ） スプリントでは、（中略） プロダクトバックログを必要に応じてリファインメントする。 スプリントプランニングのトピック2での説明（10ページ） 開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを選択し、今回のスプリントに含める。 スクラムチームは、このプロセスの中でプロダクトバックログアイテムのリファインメントをする場合がある。 それによって、チームの理解と自信が高まる。 プロダクトバックログでの説明（13ページ） 1スプリント内でスクラムチームが完成できるプロダクトバッ
プロダクトオーナーにバックログを優先順位付けさせる方法
Rustが再評価される：エコシステムの現状と落とし穴 In this article, we share findings and insights about the Rust community and ecosystem and elaborate on the peculiarities and pitfalls of starting new projects with Rust or migrating to Rust from othe...
みなさんこんにちは。@ryuzeeです。 プロダクトバックログや見積りについて質問をいただく機会が続いているので、頂いた内容と僕の回答を整理して載せておきたいと思います。 初期のプロダクトバックログの作成作業は、プロダクトオーナーがスプリント開始前に一人でやるの？ それとも、スクラムチーム全員で作成するの？開発チームで作っても構いませんが、プロダクトオーナーやプロジェクト関係者との相互理解が得られる、意味のあるプロダクトバックログを作るには、プロダクトオーナーと開発チームの協力が必須です。なお優先順位の最終決定はプロダクトオーナーの専決事項です（でないと利益の最大化の責任が取れないので）。 また初期のプロダクトバックログ作成の際には、プロダクトの目的や価値が分かっていないとそもそも項目が出せないと思うので、インセプションデッキ等を使った事前整理が必要とも思われます。 プロダクトバックログへ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
破綻したドキュメント管理、増え過ぎたプロダクトバックログ… 「Jira」「Confluence」などの活用失敗から学ぶツール運用のコツ
プロダクトバックログ項目はReadyなものだけスプリントに投入するべきという話
プロダクトバックログ項目の明確化の必要性 | Ryuzee.com
魅力的なプロダクトバックログで開発を楽しく！
なぜプロダクトバックログリファインメントはスクラムイベントに入っていないのか？
“なる早”タスクにスケジュールを乱されないための「バックログ」
プロダクトバックログにおけるよくある質問と答え | Ryuzee.com
フィードバックは選別して一旦プロダクトバックログの末尾に入れる
エンタープライズバックログを使って組織をアジャイルにしていく作戦
プロダクトバックログアイテムに取り掛かるタイミングを勘違いしてたはなし - DROBEプロダクト開発ブログ
意識すべきは「事業開発」と「プロダクト開発」の分離 PdM・PO兼任者はプロダクトバックログをどう構成したのか
スプリントバックログのタスクはどのように分解するとよいか？
トヨタのかんばんに学ぶバックログ管理術
世界のスクラムマスターはどんなツールでバックログをマネジメントしているか？
プロダクトバックログ Deep Dive
プロダクトバックログ・グルーミングとはなにか？ | Ryuzee.com
InfoQ: 仮想パネル: バックログは重要な成果物とプラクティスか、それとも無駄か?
プロダクトオーナーやプロダクトバックログに関するよくある質問と答え (1)
syncookiesとListenバックログとパケットロスト
プロダクトオーナーやプロダクトバックログに関するよくある質問と答え (2)