小さなユーザーストーリーのすゝめ ～適切な進捗把握～ Ryosuke Sugiyama

今日お話すること 開発を行っていく中で、反復内の進捗そのものが分からなかったり、 進捗と思っていたものが当てにならないなどの経験はないでしょうか？ 私自身これらの事象に悩み、どうしたら改善できるのかを考え、 ユーザーストーリーを小さくすることでこれらの事象を改善できる と気づきました。 上記を考える過程で整理した内容を元に、 たくさんある小さなユーザーストーリーにしたときのメリットの中から、 "進捗の把握"という視点でメリットについてお話しします。

みなさん、はじめまして • 杉山 亮介 • 富士通株式会社所属 • 好きなもの • Startrek🖖 • Jane Austen • @ryothkay 2016 ’19 ’20 ’21 ’22 … SaaS開発 SI アジャイル開発支援 掲載内容は私自身の見解であり、所属を代表するものではありません。 Sugiyama Ryosuke

現場で起きていたこと 反復の前半は順調に進んでいると 思っていたら、実は遅れてた。 後半遅れたら困るから見積りを盛ってし まう。 作業がなかなか完了しなく、 その間、進捗が分からない。 反復内で 何がどうなってるのか分からない。

現場で起きていたこと 反復の前半は順調に進んでいると 思っていたら、実は遅れてた。 後半遅れたら困るから見積りを盛ってし まう。 作業がなかなか完了しなく、 その間、進捗が分からない。 反復内で 何がどうなってるのか分からない。 進捗と思っているものが当てにならないから、 ドツボにハマっていってるのではないか？

ユーザーストーリーとタスクについて ユーザーストーリー タスク 目的 利用者からの要求を整理する ユーザーストーリーを速く対応できるよ うに作業の計画を立てる 記載内容 提供価値 作業計画 視点 何をしたいか どう作業するか ユーザーストーリー タスク タスク タスク タスク

ユーザーストーリーが大きいときの反復 月 火 水 木 金 計 画 ユーザーストーリーA イ テ レ 丨 シ ョ ン レ ビ ュ 丨 タスクA タスクB タスクC タスクE タスクG タスクD タスクF タスクH 追加タスク 受入確認 再受入確認 受入確認のフィードバックを対応 ユーザーストーリーAから8つのタスクを作成し5日かけて対応

どんなことが起きるのか？ 月 火 水 木 金 計 画 ユーザーストーリーA イ テ レ 丨 シ ョ ン レ ビ ュ 丨 タスクA タスクB タスクC タスクE タスクG タスクD タスクF タスクH 追加タスク ユーザーストーリーAから8つのタスクを作成し5日かけて対応 受入確認 再受入確認 受入確認のフィードバックを対応 最初の進捗確認ポイント→ 5日間進捗が分からない 結果作業が増加している

このときのバーンダウンチャート 1 ユ 丨 ザ 丨 ス ト 丨 リ 丨 数 (個) 月 火 水 木 金 進捗が分からず、見込みも立たない 0

タスクの完了で進捗を見れば良いのでは？ 月 火 水 木 金 計 画 ユーザーストーリーA イ テ レ 丨 シ ョ ン レ ビ ュ 丨 タスクA タスクB タスクC タスクE タスクG タスクD タスクF タスクH 追加タスク 受入確認 再受入確認 25% 12% 37% 50% 62% 75% 87% 100%

タスクの完了で進捗を見れば良いのでは？ 月 火 水 木 金 計 画 ユーザーストーリーA イ テ レ 丨 シ ョ ン レ ビ ュ 丨 タスクA タスクB タスクC タスクE タスクG タスクD タスクF タスクH 追加タスク 受入確認 再受入確認 25% 12% 37% 50% 62% 75% 87% 100% 進捗として100%完了しているはずだが、受入確認にて追加タスクが発生している。 タスクE,G,Hは正しいものを作れていなかったが、"完了した"と捉えて良いのか？ 単体テストが完了していたとしても、ユーザーストーリーとしての問題の有無は分からないのではないか？

このときのバーンダウンチャート ユ 丨 ザ 丨 ス ト 丨 リ 丨 数 月 火 水 木 金 0 100 (%) 20 80 60 40 一見順調に進んでいるように見える 最終日の受入確認にてバーンアップしている

タスクの完了で進捗を見れば良いのでは？ 月 火 水 木 金 計 画 ユーザーストーリーA イ テ レ 丨 シ ョ ン レ ビ ュ 丨 タスクA タスクB タスクC タスクE タスクG タスクD タスクF タスクH 追加タスク 受入確認 再受入確認 25% 12% 37% 50% 62% 75% 87% 100% タスクごとに進捗を確認できるのか？ これらを進捗の確認と言えるのか？

受入確認するまで中身は分からない 月 火 水 木 金 計 画 ユーザーストーリーA イ テ レ 丨 シ ョ ン レ ビ ュ 丨 ブラックボックス 追加タスク 受入確認 再受入確認 ブラックボックスでは完了したか、問題があるかが分からない 箱を開けるまで進捗が分からない

ならどうする？ 月 火 水 木 金 計 画 ユーザーストーリー A-A イ テ レ 丨 シ ョ ン レ ビ ュ 丨 ブラック ボックス 再受入確認 受入確認 ブラックボックスを小さくして、１つ１つ箱を開けていけば良い！ ブラック ボックス ブラック ボックス ブラック ボックス ブラック ボックス 追加 タスク 追加 タスク 受入確認 受入確認 受入確認 受入確認 再受入確認 ユーザーストーリー A-E ユーザーストーリー A-D ユーザーストーリー A-C ユーザーストーリー A-B

ならどうする？ 月 火 水 木 金 計 画 ユーザーストーリー A-A イ テ レ 丨 シ ョ ン レ ビ ュ 丨 ブラックボックスを小さくして、１つ１つ箱を開けていけば良い！ 早い段階で正確な進捗を確認可能 追加 タスク 追加 タスク ユーザーストーリー A-E ユーザーストーリー A-D ユーザーストーリー A-C ユーザーストーリー A-B タスクA タスクB タスクC タスクG タスクH タスクI タスクM タスクN タスクA タスクD タスクE タスクF タスクJ タスクK タスクL 再受入確認 受入確認 受入確認 受入確認 受入確認 受入確認 再受入確認

このときのバーンダウンチャート ユ 丨 ザ 丨 ス ト 丨 リ 丨 数 (個) 月 火 水 木 金 0 5 1 4 3 2 この時点から正確な進捗が分かる

どのくらいのサイズが良いのか？ 利用者が機能としてEnd to Endで確認できる最小の大きさ

どのくらいのサイズが良いのか？ 利用者が機能としてEnd to Endで確認できる最小の大きさ ・ユーザーストーリーの受入条件ごと ・機能テスト項目ごと サービス管理者として、ユーザー情報をメンテナ ンスするため、ユーザー一覧を確認したい 【受入条件】 • 自身の権限が管理者の場合のみにユーザー一覧画面を 開くことができること • ユーザー一覧ではユーザーのID、氏名、メールアドレ ス、ユーザーロールが一覧で表示されていること • ユーザー一覧は初期状態でIDの昇順になっていること • ユーザー一覧は任意でID、氏名、メールアドレスで並 び順を変えられること 権限 ユーザー 人数 ソート列 並び順 確認項目 管理者 10 未指定 未指定 ユーザーのID、氏名、メールア ドレス、ユーザーロールが一覧で 表示されること 一覧がIDの昇順であること 利用者 10 未指定 未指定 ユーザー一覧は表示されず、404エ ラーページが表示されること ～ 管理者 10 メールア ドレス 降順 ユーザーのIDの、氏名、メールアドレ ス、ユーザーロールが一覧で表示され ること 一覧がメールアドレスの降順であるこ と

良質なユーザーストーリーの6つの特性 I 独立している ユーザーストーリーは、他のユーザーストーリーに固有の依存関係がないように、自己完結型 である必要があります。 複数のユーザーストーリーをリリースすることで初めて価値となるようなユーザーストーリー はNG。 N 交渉可能である ユーザーストーリーは明示的な契約ではなく、議論の余地を残す必要があります。 実現する内容ではなく、作業の内容を書いてあるようなユーザーストーリーはNG。 V 価値がある ユーザーストーリーは、利害関係者に価値を提供する必要があります。 利用者から見た場合に、変化が無いユーザーストーリーはNG。 E 見積もり可能である ユーザーストーリーのサイズは常に見積もることができなければなりません。 内容が想像つかないような、あいまいなユーザーストーリーはNG。 S 小さい ユーザーストーリーは、正確さのレベル内で計画/タスク/優先順位付けを行うことが不可能に なるほど大きくすべきではありません。 複数の実現したいことが含まれているユーザーストーリーはNG。 T テスト可能である ユーザーストーリーまたはその関連する説明は、テスト開発を可能にするために必要な情報を 提供する必要があります。 利用者として何をしたいのか分からないユーザーストーリーはNG。

INVESTに照らし合わせてみると 利用者が機能としてEnd to Endで確認できる最小の大きさ N: 交渉可能である T: テスト可能である E: 見積もり可能である I: 独立している S: 小さい V: 価値がある 上記の方針で作成/分割したユーザーストーリーは、 INVESTの考え方に照らし合わせた場合でも、良質なユーザーストーリーといえる

考慮すべき事項 ユーザーストーリーが元々の利用者からの要求と乖離するため、 双方を紐づける必要がある 利用者 提供者 ユーザーストーリー A-A ユーザーストーリー A-B ユーザーストーリー A-E 機能として End to Endで 確認できる最小 ユーザーストーリーA タスク タスク タスク タスク タスク タスク タスク タスク どう作業するか 何をしたいか

考慮すべき事項 ユーザーストーリーが元々の利用者からの要求と乖離するため、 双方を紐づける必要がある 利用者 提供者 ユーザーストーリー A-A ユーザーストーリー A-B ユーザーストーリー A-E 機能として End to Endで 確認できる最小 ユーザーストーリーA タスク タスク タスク タスク タスク タスク タスク タスク どう作業するか 何をしたいか ユーザーストーリーから 利用者として何をしたいのかが分からなくなる

考慮すべき事項 ユーザーストーリーが元々の利用者からの要求と乖離するため、 双方を紐づける必要がある 利用者 提供者 ユーザーストーリー A-A ユーザーストーリー A-B ユーザーストーリー A-E 機能として End to Endで 確認できる最小 ユーザーストーリーA タスク タスク タスク タスク タスク タスク タスク タスク どう作業するか 何をしたいか

学習サイクルの高速化 ユーザーストーリーの対応から受入を小さいサイクルで繰り返すことで、 進捗のみでなく品質も確認できる 利用者 提供者 ユーザーストーリー/ コメント 要求 提供 ギャップの確認 ⇨フィードバック 学習サイクル 学習サイクルを小さくすることで高速化し品質改善ポイントの検出やチームの学習を促進できる それらにより手戻りも小さくなり開発スピードを向上しやすくなる

バーンダウンチャートの形について

ユ 丨 ザ 丨 ス ト 丨 リ 丨 数 (個) 月 火 水 木 金 0 5 1 4 3 2 あれ？なんか違和感？ バーンダウンチャートの形について

5 ユ 丨 ザ 丨 ス ト 丨 リ 丨 数 (個) 月 火 水 木 金 1 4 3 2 0 よく見かけるのはこの様な感じ バーンダウンチャートの形について

• バーンダウンチャートの目的 今の状態からイテレーションのゴールに着地できそうかを見たい バーンダウンチャートの形について

パっとバーンダウンチャートを見たときに、 "今までにどのくらい落ちた"、"線の傾きがどう"ではなく、 "線の先から0までの間"に目が行くようにしたい 線の先から 0までの 間 を見る • バーンダウンチャートの目的 今の状態からイテレーションのゴールに着地できそうかを見たい バーンダウンチャートの形について

ユ 丨 ザ 丨 ス ト 丨 リ 丨 数 (個) 月 火 水 木 金 0 5 1 4 3 2 ユ 丨 ザ 丨 ス ト 丨 リ 丨 数 (個) 月 火 水 木 金 0 5 1 4 3 2 バーンダウンチャートの形について

ユ 丨 ザ 丨 ス ト 丨 リ 丨 数 (個) 月 火 水 木 金 0 5 1 4 3 2 ユ 丨 ザ 丨 ス ト 丨 リ 丨 数 (個) 月 火 水 木 金 0 5 1 4 3 2 今まで／今日どのくらい作業が完了したかに目 が行きやすい ⇨傾き／理想線を守ることが目的になりやすい ⇨バッファ（余裕）を入れた見積りに繋がる 残りの作業量に目が行きやすい ⇨残りの期間で0を目指すことを目的にしや すい バーンダウンチャートの形について

バーンダウンチャートの形について ユ 丨 ザ 丨 ス ト 丨 リ 丨 数 (個) 月 火 水 木 金 0 5 1 4 3 2 縦軸を右側に、進行方向に向かった矢印にすることで、 今の状態からイテレーションのゴールに着地できそうかを見やすくなる

さいごに ユーザーストーリーを小さくすることで得られるメリットは 今回メインでお話した進捗の確認以外にもたくさんあります。 （ex. 内部的／外部的な品質、スピード） ユーザーストーリーは小さくすることを、 強くおすすめします！

Thank you! @ryothkay