#Agile #Product Management プロダクトバックログ上で生まれるアイテム、要件、テストなどをまとめるハブになる

#Agile #Product Management ユーザーストーリーマッピングの最上部に配置されるユーザーの主要なアクティビティの流れ アクティビティを時系列で左から右に並べ、プロダクト全体のユーザージャーニーを表現する 各アクティビティの下にユーザータスクをぶら下げ、さらにその下にストーリーを配置する

#Agile #Product Management プロダクトに必要とされるもののリスト、優先度順に並べる

#Agile #Product Management #Team Organization 10個のアジェンダをチームおよび関係者で答えていくワーク われわれはなぜここにいるのか エレベータピッチ パッケージデザイン やらないことリスト ご近所さんを探せ 技術的な解決策 夜も眠れない問題 期間を見極める トレードオフスライダー 何がどれだけ必要か 日本語のテンプレートは以下にある https://github.com/agile-samurai-ja/support

#市谷 聡啓 #Agile #Product Management Docswell ゴールデンサークル ユーザーストーリー

Authors 市谷 聡啓 #Agile #Product Management ユーザーストーリー駆動開発で行こう。 by @papanda ユーザーストーリー INVEST ユーザーストーリーマッピング

AI-Driven Development Life Cycle #Product Management AWSが提唱するAI駆動の開発ライフサイクル手法。従来のSDLCをAIファーストで再設計し、AIがワークフローを主導し人間が検証する スプリントに代わる「Bolt」という短い反復サイクル（時間〜日単位）で実行 Inception・Construction・Operationsの3フェーズで構成され、各段階に人間の承認ゲートを設置 ドキュメントファーストで全成果物・意思決定の追跡可能性を確保 https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/

#Agile #Product Management 作業バッチサイズを最小化させるための観点の頭文字を略称にしたもの Independent Negotiable Valuable Estimable Small Testable

#Agile #Product Management #Documentation プロダクトバックログアイテムが完成したと判断できる条件

#Product Management アウトプットを用いて得られる成果、ユーザーに感じてもらう価値

#Product Management #Team Organization Developers・Users・Businessの3頂点と中心にProductを置く、プロダクトマネジメントのフレームワーク（Dan Schmidt, 2014） PMの役割は各要素間の隙間（white space）を埋め、相反する入力を統合（synthesis）すること https://productlogic.org/2014/06/22/the-product-management-triangle/

#市谷 聡啓 #インセプションデッキ #Agile #Product Management https://www.docswell.com/s/papanda/ZYR1L5-shin-agile-deck

#Product Management TEDの優れたリーダーはどうやって行動を促すかによって初めて解説された考え 円の中心から Why What How の順に並ぶ Howが一番外側にあるが優先度が低いというわけではなく、HowによってWhatに大きな影響を与えるケースもある

OST #Product Management Teresa Torresが提唱したプロダクトディスカバリーのためのビジュアルフレームワーク。ツリー構造で意思決定を整理する Outcome（成果） → Opportunity（機会） → Solution（解決策） → Experiment（実験） の4層で構成 顧客のニーズや課題（Opportunity）を起点に解決策を導出し、仮説検証で学びを得る https://www.producttalk.org/opportunity-solution-trees/

Behavior-Driven Development #Testing #Agile #Product Management Dan NorthがTDDのビジネス要件との乖離の課題を解消するために名付けた考え、2006年にIntroducing BDDによって紹介された その後のコミュニティの成熟でGherkin記法の実践だけではなく、どのようにビジネスチームと一緒に製品を作り上げていくのか、に焦点が当たっている 主に以下の3つのプラクティスを行う 発見 定式化 自動化 https://cucumber.io/docs/bdd/

Minimum Viable Solution #Agile #Product Management 期待する成果を達成できる最小のリリース単位 MVPがProductという語で新規プロダクトを想起させるのに対し、Solutionに置き換えることで既存プロダクトへのリリースにも適用できるよう概念を広げている

#Agile #Product Management #市谷 聡啓 https://drr.red/

#Agile #Product Management Whoとして、Whatをしたい。なぜならWhyだからだ のように Who What Why を含む形で書かれる、ユーザーにとっての価値を説明する文 INVESTであるストーリーが良いとされる

Product Requirements Document #Documentation #Product Management プロダクトに必要な機能・振る舞いを定義する文書。開発チームとステークホルダーの間で「何を作るか」の共通認識を形成する 主な構成要素として、目的・ゴール、ユーザーペルソナ、機能要件、非機能要件、成功指標を含む

#Agile #Product Management #Documentation Jeff Pattonが考案したユーザーストーリーを洗い出すためのプラクティス 優先度付けや段階的なリリースのスコープ整理を行う Blog / Agile Studio