• 製品・サービス
  • 業種別
  • ブログ・導入事例
  • IR
  • 会社情報
  • 問い合わせ・資料請求
ご契約中のお客様
  • 製品・サービス
  • 業種別
  • ブログ・導入事例
  • IR
  • 会社情報
  • 問い合わせ・資料請求
  • ご契約中のお客様
戻る

問い合わせ・資料請求

ご契約中のお客様

リックソフトブログ

スクラム開発でスプリントの期間（イテレーション）を変えるときに注意すべきこと【Jira でスクラム開発】

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

堀田実希

堀田実希 hotta

記事一覧へ

2024年の個人目標をJira のスクラムテンプレートで管理している堀田です。

これまでの試み
▶　Jira Softwareのスクラムテンプレートで一年の目標管理をしてみる【2024年準備編】-リックソフトnote-
▶　【スクラムで目標管理シリーズ】Jira Softwareの「ストーリー」として作った課題を、「エピック」に変えたくなった。サブタスクごと階層を変えたい -リックソフトブログ-
▶　Jiraで対応不要になった課題はどうすればいいの？【スクラムで目標管理シリーズ】-リックソフトブログ-
▶　バーンダウンチャートがきれいに描けない。バグはスプリント内で処理すべき？【アジャイル開発・Jiraのスクラムテンプレート個人の目標管理シリーズ】- リックソフトブログ -

Jiraの「レポート」機能の「累積フロー図」で自分が完了したタスク量を見ると。達成感を味わえました！

これまで、一人でJiraで目標管理を振り返ってみると、自分の場合以下の発見がありました。

発見した問題考えられる原因
  • ベロシティ（生産性）はまったく安定しない
  • スプリントバックログの積み方が適当になりがち
  • スプリントゴールがあいまいなままスプリントをスタートしている
  • ベロシティが安定しない要因のひとつに、家族や自分の体調不良など予期せぬイベントが多発していることが考えられる
  • ストーリーポイントの見積もりが甘い
  • 課題の粒度にばらつきがある
  • デイリースクラムをやっていない

この2024年目標管理プロジェクトは、プロジェクトオーナーもプロジェクトメンバーもスクラムマスターも自分一人の兼任体制で、そもそも一人なのでスクラムを組みようがないと思っていたのですが、ステークホルダーに家族がいたということに気づかされました。

もしかしたら家族にスプリントプランニングに入ってもらったらうまくいくかもしれませんが、そんな家族関係ではないのではやばやと諦めることにします。

堀田は、Jiraで2024年の目標管理をしているメンバーで定期的に集まり、反省会をしております。

そこで、「やっぱり１スプリントが一か月ってのは長いんじゃない？」と指摘されました。スプリントが一か月と長く、一人でやっているからスプリントゴールが適当になるあいまいになる。そんな気もしてきました。

イテレーション期間を変えるときの必須事項：チームとして合意する

前述のとおり、堀田のプロジェクトはプロジェクトオーナーもプロジェクトメンバーもスクラムマスターも自分一人の兼任体制なので、誰かの合意をとる必要はありません。

じゃあ実際の開発メンバーがイテレーション期間を変えるときに何を気を付ければいいのか、社内のスクラムマスター何人かに聞いてみました。

< こんな記事もあります！！ >

★ プロダクトバックログとは？項目や書き方、アジャイル開発での位置付けも解説

★ アジャイル開発でよく聞くスクラムとは？ チームの構成要素やプロセスについて解説

★ アジャイル開発とは？メリット・デメリット、代表的な手法を解説

■リックソフトのスクラムマスター、山口さんの回答：開発のリズムが崩れる可能性があることに留意

まず気を付けるべき点として、以下の2点が挙げられるかと思われます。

  • リリース頻度が２倍になる＝イベント（特にスプリントプランニング、スプリントレビュー、スプリントレトロスペクティブ）の実施頻度も２倍になる
  • 開発チームのリズムを崩すことになる
  • チームメンバーの合意をとる

スクラムでは「リズムを一定にするべき」という考え方があります。

もしスプリント期間がちょくちょく変わると、開発チームがスプリント期間内にコミットできる作業量も把握しきれなくなります。

そしてチームメンバーの合意は必須です。期間変更が管理者側の都合である場合、やってはいけません。

どれほどの期間で何を実施するかは開発チームが決める話で、彼ら抜きに話を決めるのは絶対NGです。

■さいきんイテレーション期間を変えた濱田さんの回答：チームの合意は必須

注意すべき点は、まさに「チームの合意を得る」ことだとおもいます。開発メンバーが変更の必要性を感じていなければ、原則通り変えないほうがよいだろうとおもいます。

スプリント期間を２週間から４週間に変更した理由

社内システムの開発をしている濱田さんチームは２か月前にスプリント期間を２週間から４週間に変えました。

変更した理由は、メンバーがスクラム開発に慣れておらず、目標とするスプリントゴールを達成できないことが続いたためです。スプリントの期間が短いと、その分イベントの実施回数が増えてしまい、それらに時間をとられてしまいます。

慣れないうちは、開発の速さを重視するのではなく、じっくりタスクの量を見積もり、きちんと時間をかけて1つ1つ対応できる余裕を作ろう...という狙いから、イテレーション期間を２倍にしました。

結果として、いまのところうまくいっています！

イテレーションを変えるときに注意すべきことのまとめ

チームとしての合意は必須。

イテレーションを短くすればその分スクラムイベントの回数が増えるため、改善がはやい一方、スクラムイベントの回数が増えてしまいます。

スプリントゴールを達成しない状況が続くならばイテレーションを長くする方法も選択肢に入れていいのですが、なんにせよチームとしてのの合意は必須です。

本ブログのカテゴリ： Jira

堀田実希

堀田実希 hotta

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

本情報はブログを公開した時点の情報となります。

« 

研修ページ

サポートブラス

最近の記事

　　
資料ダウンロード お問い合わせ PAGE TOP
資料ダウンロード お問い合わせ