nDiki : プロダクトバックログ

スクラムプロダクトバックログ (Product Backlog)

フィーチャー・不具合・技術的な作業など、プロダクトに必要でプロダクトオーナーから見て価値のあるものが優先順位付けされて並べられたリスト。

2017年10月24日 (火)

「複数のチーム、1つのプロダクトバックログ」リトライの機運

プロダクトバックログを1つにしたいという意見が出てます。優先度判断の上でも理想的な形だと思う一方、 LeSS (Large-Scale Scrum) のようなフレームワークを取り入れたりする必要があるので軌道にのせるには考えることもいろいろ増えます。

「複数のチーム、1つのプロダクトバックログ」はまだ成功体験がないのでまたトライしてみたいと思うところです。

スポンサード リンク

今日のさえずり: エレコム、まだハンドスピナー出すのか……

2017年10月24日

[ 10月24日全て ]

2017年11月7日 (火)

会議室が広すぎる気がしたので来週から狭い部屋にしてみる【日記】

ThinkPad キーボードをチェンジ

家では使わなくなってオフィスにもってきていた「ThinkPad Bluetooth ワイヤレス・トラックポイント・キーボード」をようやく MacBook Pro とペアリングしました。今まで使っていた「ThinkPad USB トラックポイントキーボード」とは違ってケーブルが邪魔にならないし、パームレストが無いぶんデスクが広く使えるようになったしで快適になりました。

広すぎる会議室問題

スプリントプランニングやプロダクトバックログリファインメントで使っている会議室が横長な部屋で、座る場所によってはどうも遠い感じがしたので来週からもうちょっと狭い部屋に変えてみることにしました。もうちょっと話し合いやすくなるかな?

[ 11月7日全て ]

2017年11月17日 (金)

push よりも pull

ポートフォリオプランニングについてディスカッションしている時に「各チームがバックログから pull して……」と言われて、あーポートフォリオバックログからプロダクトバックログへの流れも pull で考えた方がシンプルでいいなとあらためて思いました。

[ 11月17日全て ]

2017年12月7日 (木)

Trello ボードをかんばんとして使う時のプロジェクトからのタスク切り出し

最近編成したチームのタスク見える化として Trello ボードでかんばんをまず作りました。TODO・DOING・DONE リストをベースとしたよくあるボードです。

TODO・DOING・DONE をリストとして分割した場合どれが進んでいるわかりやすいのですが、プロジェクト(複数のタスクが必要な仕事)の扱いが迷いどころです。一気にタスク分割するわけではないので、分割した残りを表すカードを TODO に置いて REST と書くようにしていますが他にいい方法あるかなぁ。

ちなみにスプレッドシートで管理しているプロダクトバックログでもプロダクトバックログ(PBI)を分割した際は具体的な PBI と 残り全体の PBI にしていたりします。こちらは一列に並んでいるので、切り出された PBI は必ず残り全体の PBI より上にあるのでまだわかりやすいんですよね。

[ 12月7日全て ]

2017年12月11日 (月)

今日のさえずり: お腹すいたけど、もらったビスコをこの時間に食べちゃいけない気がしている

2017年12月11日

[ 12月11日全て ]

2018年2月6日 (火)

今日のさえずり: チームのかんばんの優先順位会議というかレビューをした

2018年02月06日

[ 2月6日全て ]

2018年2月16日 (金)

エッセンシャル スクラムを読む会: 第16章 ポートフォリオプランニング

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

今のチームでポートフォリオプランニングの運営をしているので、勉強のためチームメンバでエッセンシャル スクラムの「16章 ポートフォリオプランニング」を読む会をやりました。昨年度に別のメンバで1冊通しでエッセンシャル スクラムを読む会をやって以来なので久しぶりです。

今回の自分のパートは以下。

  • 16.5 アウトフローの戦略
  • 16.5 仕掛品の戦略
  • 16.6 終わりに

「プロダクトをいつポートフォリオバックログから取り出すか」についてのアウトフローの戦略は

  • 「作業者の手待ちではなく、作業の手待ちに注目せよ」
  • WIPを制限する」
  • 「チーム全員の準備が整うのを待つ」

ポイントでこれらは、スプリントプランニングに通じるものがあるのでわかりやすいところです。

仕掛品の戦略は作業中のプロダクトについて

  • 維持
  • デリバリー
  • ピボット
  • 打ち切り

を判断するための戦略です。限界費用で考えましょうということ。限界費用が適切に見積もれる必要がありますが、そこが難しいところですね。

16章を通して11の戦略が示されていますが、おわりにの節でどれかを選ぶとしたらとして 11の戦略から選ぶとしたら

  • 遅延コスト
  • 小さめのリリースを頻繁に
  • WIP を制限する
  • 限界費用

だとのこと。参考にします。

やはりポートフォリオレベルでは収益とコストをしっかり考える必要があるなと。

読み直して、やはり今ポートフォリオバックログと呼んでいるのは階層化プロダクトバックログだなと。複数チームで取り組んでいるのでそれはそれで必要なのですが、ポートフォリオプランニングという意味では考え直したいところです。

[ 2月16日全て ]

2018年7月2日 (月)

ポートフォリオバックログのスプレッドシートに概要レベルのプロダクトバックログ列を追加

ポートフォリオバックログ」のスプレッドシートに「概要レベルのプロダクトバックログ」列を追加したら、プランニングでより具体的な話し合いができるようになりました。

  • 各アイテムが何をやるのかが明確になり共通認識になる。
  • 内容が明確になることで規模感を考えられるようになる。
  • 完了条件ではなくプロダクトバックログにすることで、柔軟に再計画できる。

みたいなメリットが生まれました。

今日のさえずり: まだ1年の半分終わっちゃいない! 7月2日正午までまだもうちょい!

2018年07月02日

[ 7月2日全て ]

2018年7月27日 (金)

プロジェクトでみんなをバスに乗せるために書いておく項目リスト

みんなをバスに乗せるためにプロジェクトのプランニングで明確にして共有した方が良いドキュメント形式って、方法論やプロジェクトの段階によっていろいろな名前のものがありますが、基本的に項目はどれも似たような感じです。

項目名を整理して決めておくと楽なのでちょっと書き出してみました。

コンセプトシート

比較的軽量にまとめる時。

  • タイトル
  • 概要 (What)
  • 目標 (Goals)
  • 背景と目的 (Why)

プロダクトプラン

プロダクトプランニング(エンビジョニング)のアウトプットとして。エピックレベル(数カ月程度の大きさ)。

  • プロダクト名
  • プロダクトビジョン
    • 概要
    • 目標
    • 背景と目的
    • 成果物
    • 完了条件
    • スコープ(含むの・含まないもの)
    • (opt) 依存するプロジェクト・制約条件
    • (opt) リスク
    • (opt) 予算
    • (opt) メンバ
  • 概要レベルのプロダクトバックログ
  • プロダクトロードマップ

ポートフォリオバックログアイテム

ポートフォリオプランニングで、プロダクトプランを評価した結果のもの。エピックレベル(数カ月程度の大きさ)。

  • プロダクト名
  • プロダクトプラン
  • 期間
  • 遅延コスト(ビジネス価値・時間価値・リスク軽減/チャンスと利用)
  • WSJF

プロダクトバックログアイテム

スクラムで1スプリントで完成できるサイズのアイテム。フィーチャーレベル。

タスクチケット

ちょっとしたタスク。

  • タスク名
  • 概要
  • (opt) 背景と目的 (概要で自明でない場合)
  • (opt) 成果物/アクション (概要で自明でない場合)
  • 完了条件
  • 期日

プロジェクト憲章

  • プロジェクト名
  • 概要
  • 目標
  • 背景と目的
  • 成果物
  • 完了条件
  • スコープ(含むもの・含まないもの)
  • (opt) 依存するプロジェクト制約条件
  • (opt) リスク
  • (opt) スケジュール・期限
  • (opt) 予算
  • (opt) メンバ

備考

他には以下のような形式もあります。

  • One Pager
  • インセプションデッキ
  • 製品要求仕様書 (PRD: Product Requirements Document)
  • リーンキャンバス

[ プロジェクトマネジメント ]

[ 7月27日全て ]

2018年10月3日 (水)

組織サーベイと見積もりゲーム

アンケート調査による組織サーベイ、「スクラムにおけるプロダクトバックログアイテムの見積もり」の最大の目的が「話し合う過程でいろいろな気付きを得ること」だというのと同様に考えて使うのは確かにアリだなと。

[ 10月3日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

follow us in feedly

月別インデックス
Process Time: 0.077668s / load averages: 0.42, 0.38, 0.45
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker