スクラムをうまく回すために受け入れ基準をきちんと書く - SmartHR Tech Blog

はじめに こんにちは。12月1日より、プロダクト開発のディレクションを担当している三好と申します。スクラムの役割定義で言うと、プロダクトオーナー（以下PO）がしっくりくるかと思います。 みなさんの開発現場では、スクラムがきちんと機能していますか？ POとスクラムマスター、エンジニアがきちんとコミュニケーションをとって開発を進められていますか？ 今回は、「受け入れ基準をきちんと書くこと」をテーマに本記事を書きます。 背景 弊社は、昨年9月11日に開催したSmartHR Next 2018で、「SmartHR」のプラットフォーム化構想を発表しました。 これに伴い、雇用契約機能や年末調整機能、店舗向けのiPadアプリなど、SmartHR本体と連携する機能と、SmartHR本体の開発をチームを分けて進めていく体制に移行をしていきました。 機能が増えるということは、機能に対するビジネス要件もより広範

[kajinari]

「スクラムをうまく回すため」なんだ。 価値を早く届けるためとか、ビジネス上のアウトカムを得るためにプロセスを整備することにフォーカスして欲しい。

[carolina04]

“その機能をどうデモするか？　テストするか？ という観点で受け入れ基準を書いてみると、 どういう要素・条件が必要か。ということがわかります。 上記では性能要件などは記載していないのですが、同時アクセ”

[braitom]

ほんとその通りだよなあ “チケットが絶対必須の条件として備えていなければならないことは、 実現したいユーザーストーリー（もしくはビジネス要求）が、誰が見ても迷いなく理解できる状態で明確になっている”

[jakalada]

“受け入れ基準を書く段階で、？がたくさん浮かぶようであればそれはまだ開発GOすべきチケットではないと言えます。”

[takatoshiono]

曖昧さなくすの大事

[tune]

「受け入れ基準が曖昧なものは見積もりしない、見積もりされてないものは着手しない」がいいかな。あとスプリント中POにまめに質問・確認できればなお良い。スプリントレビューはPOに確認してもらう場では無いはず。

[chrl-ohya]

これ、めちゃ良い話。開発に限らず何かチケット的なものを作るときは他の職種でも意識できると良き。