【Jiraでのアジャイル開発】バーンダウンチャートがきれいに描けない。バグはスプリント内で処理すべき？【クラムテンプレートで個人の目標管理シリーズ】

2024年07月26日
【Jiraでのアジャイル開発】バーンダウンチャートがきれいに描けない。バグはスプリント内で処理すべき？【クラムテンプレートで個人の目標管理シリーズ】

Author

堀田（リックソフト　マーケティング部） hotta

堀田（リックソフト　マーケティング部）</mt:Var>

Jira Cloudでスクラム開発をされているみなさん、バーンダウンチャートでプロジェクトの進行具合を確認していますか？

カンバン、プロダクトバックログ、スプリント、ストーリーポイントなどアジャイル開発を進めるうえで便利な機能が詰まっている「Jira」のスクラムテンプレートは、「これを使っていると自然とスクラム開発のお作法に沿って開発ができる」というすぐれものです。

私、リックソフトのマーケティング部の堀田は、2023年の年末から、2024年の個人目標管理をJira Software（ジラ・ソフトウェア）のスクラムテンプレート（チーム管理対象プロジェクト）を使って進めています。

▶ Jira Softwareのスクラムテンプレートで一年の目標管理をしてみる【2024年準備編】-リックソフトnote-

▶ 【スクラムで目標管理シリーズ】Jira Softwareの「ストーリー」として作った課題を、「エピック」に変えたくなった。サブタスクごと階層を変えたい -リックソフトブログ-

▶ Jiraで対応不要になった課題はどうすればいいの？【スクラムで目標管理シリーズ】-リックソフトブログ-

管理をはじめて、半年が経とうとしています。だいぶ Jira の使い方にも慣れてきました。プロダクトバックログにいつまでも残っているタスクがあるのを見て、どこかで見た"「腐ったバックログ」と言葉の意味はこういうことか..."と納得感を持っています。

最近は私生活で「虫歯」や「スマートウォッチが壊れた」などトラブルが頻発しており、スプリントの途中にバグとしてチケットを起票するようにしました。

スプリント期間中に見つけたバグをスプリント期間中に対応すると、バーンダウンチャートが凹凸になるので、なんだかモヤモヤします。まっすぐ右下がりの線が理想なのに...

バグは同じスプリント内のタスクに追加しないべきなのでしょうか？　それともバグはJiraのスクラム開発では無視すべきなのでしょうか？

とはいえ、すぐに対応しないといえかにバグは発生するものでしょう。バグについては起票しないで対応すると、あとから追跡できなくなります。本来課題遂行に充てるべき時間と労力がバグ解決に向かうため、従来のストーリーポイントは下がらず、バーンダウンチャート上ではさぼっているようにも見えてしまいます。どうすべきなのでしょうか？

社内のスクラム開発・アジャイル開発に詳しい人に相談してみました。

まず確認【Jiraでアジャイル開発】バーンダウンチャートとは？
バグはスプリント内で必要に応じて直しましょう
「きれいなバーンダウンチャートを描く」を目標にしてはいけない
柔軟に対応している状況が可視化されることが大事

まず確認【Jiraでアジャイル開発】バーンダウンチャートとは？

バーンダウンチャートは、プロジェクトの進捗状況を右下がりの折れ線グラフで図示し、実績値の計画や理想からの乖離を一目で把握できるものです。スプリント後に振り返る際、チームと個人のパフォーマンスを見る材料の一つです。

Jiraのスクラム開発テンプレートでは、横軸が日にち、縦軸がスプリントに割り当てられたスプリントバックログのストーリーポイントの累計値を示すレポート機能が標準で搭載されています。（Freeプランでもこの機能は利用できます）

日を追うごとに残りの累積ストーリーポイントが下がっていき、スタート時からスプリント終了時まで、ガイドラインに沿って右下にまっすぐ行くのが理想とされています。（上の図は、リックソフトの開発チームが提供してくれた美しいバーンダウンチャートの一例です）

バグはスプリント内で必要に応じて直しましょう

アジャイル開発に詳しいリックソフト社員・廣田さんの話（元 Excel-Like Bulk Issue Editor for JiraのProduct Manager）

バグ、と一言でいっても様々な種類があるので一概には言えないですが、既存のソフトウェアやサービスで致命的な不具合が見つかったのであれば、それがスプリント計画外の作業であっても即対応しましょう。顧客への価値を最大化につながる大事な工程です。

私の場合、

デグレードや致命的なバグ→スプリントに入れて即対応
既知の不具合でワークアラウンドがある→プロダクトバックログに入れて「いつかやる」タスク扱い

というようにしています。

「きれいなバーンダウンチャートを描く」を目標にしてはいけない

そもそも、堀田さんの場合、「きれいなバーンダウンチャートを描くこと」が目的になってませんか？

スプリントバーンダウンチャートは、あくまでスプリントの結果として指標にするものです。計画通りバーンダウンしなかったのであれば、何か原因があったということがわかります。
その原因が、割り込みで入ってきた不具合修正（バグ対応）タスクなのか、メンバーのコンディション不良なのかは、あとで振り返って分析すればいいのです。