こちらのアドベントカレンダーの23日目に参加させて頂きました。

アジャイルにおける設計、リリースプランニング

前にクリーンアーキテクチャの内容を紹介するセッションやったときにアジャイルでのアーキテクチャとか設計ってどうするん？ってなって、アジャイルにおけるPBIをbuildしていく際の設計について調べたことがありました。
その時の内容はこちらの記事で紹介しているスライドの「アジャイルとアーキテクチャ」のセクションで取り上げています。

とはいえProduct BacklogにPBIとして登録する前にも「こういうのが欲しい」みたいな抽象的なアイデアからどうやってPBIぐらいの具体的なアイテムに落として開発できる状態にrefineしていけばいいのかとか、リリースまでの絵図どう描けばいいのかとかのハイレベルな設計がいるよね？そういうのどうすればいいんだろう？って考えていたところ、ユーザーストーリーマッピングという手法を知ったのでこの本を読んで、
https://amzn.asia/d/cdDwGbI

お仕事で実際にやってみる機会があったので、今回はユーザーストーリーマッピングのstep by stepでのやり方を簡単に紹介し、それらでリストアップされたユーザーストーリー群をAzure DevOpsのScrum Processのwork itemにマッピングしてBacklogsに登録するステップまでを紹介しようと思います。

スクラム開発におけるProduct Backlogの意義

ここで、スクラムにおけるProduct Backlogの意義についておさらいしておきます。
とりあえずScrum Guide 2020を見ると、Product Backlogは以下のように定義されています。

プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの⼀
覧である。これは、スクラムチームが⾏う作業の唯⼀の情報源である。

Product Backlogは、そのチームが一丸となって達成すべきプロダクトのゴールを達成するためのやることリストのようなもので、開発者はこのProduct Backlogに登録されたPBIを開発、リリースをしていきます。

Azure DevOpsでは、Boards > BacklogsをProduct Backlogとして運用できます。

Azure DevOpsにおけるポートフォリオバックログ（in Scrum Process）

スクラムでは1つのプロダクトに対応するProduct Backlogは1つだけで、そこにはPBIだけが含まれます。

Azure DevOpsではEpic > Feature > PBIといった感じでwork itemを階層的に管理できるポートフォリオバックログの機能が提供されています。全体像を描いてビジネス上の取り組みの達成としてのEpicsを定義し、そこからリリース可能なFeaturesに落とし、さらにそのFeatureを小さな実行可能なサイズのアイテムとしてPBIに落としていきます。

これにより、ビジネスイニシアチブの下でバックログを整理することができ、中長期的なビジョンや戦略を踏まえたデリバリーやタスクマネジメントをサポートしてくれます。

このwork itemを階層的に管理する方法は、ProcessがScrumでもCMMIでも、いずれのProcessでもサポートされています。
（BasicのみBacklog levelの上のレイヤーはEpicのみ）

ユーザーストーリーマッピングとは

上記のEpic, Feature, PBIが表す内容から考えると、最終的に求めているものをリリースするためには、全体像を描いた上で、その中でのいくつかの達成のマイルストーンを識別して機能に落とし込み、さらにそれを実行可能な単位までに分割したデリバリーする価値に落とし込み、、、というのを考えるタイミングが必要です。
この全体像からPBIまで落とし込む作業をすることによって、リリース計画などのデリバリーの全体を踏まえたProduct Backlogを作成することができます。

ユーザーストーリーマッピングはこういったことを考えるための手法です。

ユーザーがプロダクトをどのように使用していくかのジャーニーを描いて、
ユーザーの各アクティビティから、それを実現するための具体的なユーザーストーリーにマッピングしていくことで、Product Backlogに登録していくべきEpic, Feature, PBIを識別していきます。

ユーザーストーリーマッピングの主な目的は、ユーザーの体験を全体的に把握し、製品やサービスが提供すべき価値と機能を明確にすることです。これにより、スクラムチームはユーザーの実際のニーズに基づいた機能や改善点を優先順位付けし、より効果的なプロダクト開発を行うことができます。

ユーザーストーリーマッピングのプロセス

ユーザーストーリーマッピングのプロセスはこんな感じです。

プロダクトを使用するユーザーのペルソナを特定する
ユーザージャーニーを描く
ユーザーのジャーニーの中での各アクティビティを実現するためのユーザーストーリーをリストアップ
潜在的なリスクの検討
ユーザーストーリーの順位付けをしてリリース計画を検討

こんな感じのフレームワークを用意して進めていきます。

ちなみに、MSのWhiteboardアプリではユーザーストーリーマッピングのテンプレートが提供されています。

今回は、Azure DevOpsのようなDevOpsライフサイクルをサポートするDevOpsソリューションのプロダクト開発を例に挙げて、ユーザーストーリーマッピングを進めていきます。

step1: プロダクトを使用するユーザーのペルソナを特定する

まずはプロダクトに関わる登場人物のペルソナを描いていきます。
DevOpsソリューションに関わる人たちなので、こんな人たちが関わってくるかなと思います。

みんなそれぞれ色々思うことはありつつも、セキュリティが担保された状態で快適にDevOpsのライフサイクルを回して幸せになりたいと思っています。

step2: ユーザージャーニーを描く

登場人物として開発者、オペレーター、PdM、セキュリティ部門をあげたので、それぞれの登場人物の目線からプロダクトに関わるユーザージャーニーを描いていきます。

このジャーニーの中での各アクティビティが、Azure DevOpsのポートフォリオバックログでのEpicやFeatureになっていきます。

Epicはビジネス上の達成を表すので、この中で出されてるやつを俯瞰してこれはプロダクトの全体像の中でも大きなマイルストーンのひとつになるようなやつがあればそれをEpicにしてもいいですし（DevOpsソリューションを作ってるんだとしたらDev-Opsのコラボが重要になるから「チームとのコミュニケーション」をEpicにするとか）、

あとはフィードバック系のアクティビティをいくつかまとめて「継続的なフィードバックの共有」とかに切り出してもいいかなと思います。

step3: ユーザーのジャーニーの中での各アクティビティを実現するためのユーザーストーリーをリストアップ

各登場人物のユーザージャーニーを描いたところで、各ジャーニーでのアクティビティを達成するためのstepをユーザーストーリーとしてどんどん出していきます。

例えば、ユーザージャーニーでの統合、テストのアクティビティでのユーザーストーリーは、
開発者としてはコードのCI/CDができてその結果が確認出来るとか、オペレーターはテストの結果によってはデプロイ作業を止めることができる、といったようにWho, Whatを明確にして書くと、このユーザーストーリーは誰のためにどういった価値が提供できるかがわかりやすくなります。

この段階では、GitHub Actionsを使う、とかAzure DevOpsのリリースゲートを使ってTeamsで承認もらえるようにChatOpsして、、、という具体的な実現方法は書かず（それはこのユーザーストーリーをやる！と決まってから考える）、「どういう状況になっていればよいか」にフォーカスします。

また、ここでは優先順位は一旦考えず（あとでやるので）、とにかくどんどんユーザーストーリーを出していきます。

このユーザーストーリーたちが、Azure DevOpsのポートフォリオバックログではPBIに相当します。

step4: 潜在的なリスクの検討

上がったユーザーストーリーを眺めながら、全体的なストーリーの中で潜在的なリスクを検討します。ここで潜在的なリスクを考慮することで、開発チームはどのユーザーストーリーが最も重要か、どの機能が最もリスクが高いかを評価し、適切に優先順位を付けることができます。

リスクストーリーのレーンを追加してもいいですし、既存のストーリーの上にこんな感じで色違いの付箋を貼ってもいいでしょう。

step5: ユーザーストーリーの順位付けをしてリリース計画を検討

では、上がったユーザーストーリーと、検討したリスクを踏まえて、ユーザーストーリーの優先順位を付けていきます。
できることなら全部やる！としたいところですが、リリースのために使える期間とリソースには限りがあるので、最も避けたいリスクや最も早期に達成したいことは何かにフォーカスして、優先順位を付けていきます。

今回は、Step4でリスクを上げた結果、セキュリティ的なインシデントの発生やリリース後の不具合によるクレームが最も避けたいリスク、そして開発者、オペレーター、セキュリティ部門、PdMのコラボレーションができることを優先したい、という気持ちになったとして、これらのリスクを確実に回避してプロダクトリリースができるようにユーザーストーリーの優先順位づけをおこなっていくとします。

優先順位が決まったら、リリース対象を検討していきます。
こんな感じで線を引いて、ここから上はリリース対象、ここから下は今回のリリース対象外、とわかるようにします。

Azure DevOpsのポートフォリオバックログに登録

対応するユーザーストーリー群が決定したら、ユーザーストーリーマッピングで特定したユーザージャーニーのアクティビティとユーザーストーリー群をEpic, Feature, PBIにマッピングしてAzure DevOpsのBacklogに登録します。

Azure DevOpsのBacklogからいっこいっこ登録するのも面倒なので、CSVインポートで一気に登録できるようにCSVでこの感じのフォーマットでwork itemにマッピングしていきます。

work itemの一括インポートは、Azure DevOpsのBoards > Queries にいって、Import work itemを選択

ここで作成したCSVを選択して、Importを押下

こんな感じで一気に登録されます。

ここでSave Itemsを押下して、登録したwork itemたちを保存します。

Boards > Backlogsにいくと、登録したwork itemたちが確認できます。

Backlog Itemsの箇所で、表示するBacklogのレベル（PBI, Features, Epics）を変更できます。
※Backlog itemsがPBIのみが表示される

階層的に見たい場合は、View Optionsから、ParentsをOnにすると、

こんな感じでEpic, Featureを含めた階層的なバックログが表示されます。

Product BacklogのメンテナンスとPBIのリファインメント

これで開発対象のユーザーストーリー群が登録され、Backlogができました。
しかし、Backlogはそのままにしておくのではなく、いうまでもなく継続的なメンテナンスとリファインメントが必要です。

実際プランニングに対してReadyな状態（この状態であればもう開発できる状態）にするためには、work itemを登録するだけでは不十分で、Acceptance Criteriaの定義やDescrriptionのRefinementを通して、INVEST^[1]の状態にしていく必要があります。

Product Backlogはプロダクトの目標とそれを達成するための方向性を反映するので、優先順位が常に現状を反映するように継続的にメンテナンスをしていくことが必要です。

まとめ

ユーザーストーリーマッピングによって、ユーザーニーズを反映して全体像を描いた上でユーザーストーリー群の抽出を行うことができます。
また、Azure DevOpsではビジネス的なイニシアチブの下でバックログを整理することができるポートフォリオバックログの機能が提供されているため、ユーザーストーリーマッピングと組み合わせることによってより精度の高いポートフォリオバックログを作成することができます。

アジャイルデリバリーに関わる方、Azure DevOpsのポートフォリオバックログをもっと使いこなしたい！という方のご参考になれば幸いです。

Other References

ユーザーストーリーマッピングについてはこちらもどうぞ。

https://note.com/ookwr/n/n675da572dcf4

Azure DevOpsのポートフォリオバックログ、各種work itemの運用についてはこちらの本もどうぞ
https://amzn.asia/d/dtQtvpN

脚注

アジャイルソフトウェア開発において、良質なPBIを作成するための特定の頭文字を取ったもの（I: Independent（独立している）N: Negotiable（交渉可能である）V: Valuable（価値がある）E: Estimable（見積もり可能である）S: Small（小さい） T: Testable（テスト可能である）https://ja.wikipedia.org/wiki/INVEST ↩︎

Discussion