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

2024年07月26日（2025年08月07日更新）

堀田実希

堀田実希 hotta

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）

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

私の場合、

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

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

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

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

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

柔軟に対応している状況が可視化されることが大事

アジャイルに詳しい方の話

バグを発見した場合、そのスプリントで解決するかは、そのプロダクトオーナーやチームの判断になります。

重要なバグなら現スプリントで対応しますし、軽微ならバックログに入れますね。

理想的なバーンダウンチャートは、計画時に精度の高い見積りをして、見積り通りに事が進めたものですが、それよりも重要なのは柔軟に対応することと、そしてそれが可視化されることだと思います。開発するなかで新しいタスクの追加や予期しない遅延などは起こりえます。

スクラム開発に慣れないうちは、堀田さんのようにバーンダウンチャートが下がったり上がったりボコボコしてしまいます。

それは見積精度が低かったり（最初は安定しないです）状況が変わってたり、実際にタスクをこなせなかったりしているのかなと。

また、イテレーション（スクラム開発での開発期間の単位）が長いと見積りもブレます。スクラム開発をはじめる初期のプロジェクトでは、イテレーションは1週間など短く試してもいいかもしれません。

知りたかったことは解決しましたか？

リックソフトは、Jira・Confluenceの最新機能や使いかたを紹介するブログを更新しています。
そのほか、ガイドブック、eラーニングを提供しています。

リックソフトのガイドブックを見てみませんか？

Atlassian製品を販売して16年になるリックソフトは現在Jira（管理者向け・ユーザー向け）Confluence（管理者向け・ユーザー向け・マクロリファレンス）Jira Service Management（管理者向け）を出版しています。

企業によってはeラーニングやデジタルガイドブックがすでに入っているケースもあるので、エンドユーザーの方はいちど製品管理者に「ガイドブックありますか？」と確認してみてください。

ガイドブックを詳しく知る

本ブログのカテゴリ： Jira

堀田実希

堀田実希 hotta

この人が書いた他の記事を読む