ストーリー(チケット)に「やらないこと」を明記したら、認識齟齬が減って良かった

ストーリー(チケット)に「やらないこと」を明記したら、認識齟齬が減って良かった

GitHub IssuesBacklogなどのプロジェクト管理ツールをよく使います。 そのとき、各ストーリー(チケット)に「やらないこと」を明記すると、認識齟齬が減って良かったのです。
Clock Icon2020.09.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

システム開発時、GitHub IssuesやBacklogなどのプロジェクト管理ツールを使います。 細かい点は異なると思いますが、ストーリー(チケット)内におおよそ下記を記載していると思います。 不具合であれば、発生環境・再現手順・発生現象・期待動作なども書くでしょう。

  • 背景(何が課題で、どうしたいのか、など)
  • 完了条件
  • やったこと

そんなストーリー(チケット)なのですが、「やらないこと」を記載するようにしたら、開発チームやプロダクトオーナーの認識齟齬が減ったのです。

おすすめの方

  • チケットでプロジェクト管理をしている方

ストーリー(チケット)にやらないことを明記する

やらないことの例

ストーリー(チケット)の内容によって異なりますが、たとえば下記です。

  • デザインを正確に実装するとは限らない
  • データの一覧を表示するとき、フィルタリング機能は実装しない
  • xxxに関するチューニング作業は行わない
  • 画像の拡大縮小(ピンチイン・ピンチアウト)は行わない

やらないことを明記する理由

なんと言っても、関係者間の「アレもやると思ってた」という認識齟齬が無くなるのが大きいです。 関係者間とは、開発チームとPO(プロダクトオーナー)間でもあり、開発チーム内のAさんとCさん間などが考えられます。 やらないことを明記することが目的ではなく、やらないことを話し合って完了条件の精度を上げることが目的です。 そのため、やらないことが無い場合は無理に書く必要はありません。無しでOKです。

次のような場面に遭遇した方は意外と多いのではないでしょうか。

  • 実装時、開発者が「コレやソレってどうするんだろう? POに聞かなきゃ」となり時間がもったいない
    • 場合によっては見積もりがずれてスプリントゴール(や納期)の調整が必要になる
  • 対応後のレビュー時、POから「アレもやると思ってた」と言われる
  • 開発チーム内のレビュー時、AさんとCさんで完成形の認識違いが発覚する
    • Aさん「hogeの対応も必要ですね」
    • Cさん「え、なんで? 不要でしょ?」

事前に気づいて話し合えば、これらの発生を防ぐことができます。 また、やらないことをPOと事前に合意することで、やることの明確化や見積もり精度の向上も期待できます。

全体のテンプレート例

たとえば下記のような形です(ストーリー全体のテンプレート例)。

# 背景
- 記載する

# 完了条件(できるようになること)
- 文で書く(体言止めしない)

# やらないこと
- 文で書く(体言止めしない)

# 実施した内容
- 対応時に記載すること

ポイントとしては、体言止めしないように記載します。もしも、やらないことに「xxxの表示」とだけ書いてある場合、次のように疑問だらけになります。

  • 表示がなに?
  • 表示するの? しないの?
  • 表示はするけど、内容が違うの? 色が違うの? フォントが違うの?

具体的な記入例

簡易的な内容ですが、たとえば下記です。 もし、別のストーリー(チケット)で対応するなら、その旨も記載するとトレーサビリティ的に良いですね。

# 背景
- xxxが発生したとき、すぐに知りたい

# 完了条件(できるようになること)
- ユーザは、xxxが発生したときに電話を受け取る
- 電話の発話メッセージは「yyy」とする

# やらないこと
- ユーザが確認したらn番を押す、みたいなことはやらない(#1234 で対応する)
- ユーザが電話に出なくても、2回目以降の電話はしない
- 電話の非通知設定はしない

# 実施した内容
- 対応時に記載すること

さいごに

ぜひ、「やらないこと」を明記してみてください。今まで気づかなかった事柄や視点で話し合えると思います。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.