はんなりと、ゆるやかに

アジャイル、スクラムが好きなITエンジニアが日々から学んだことをアウトプット

共感が止まらない「スクラム現場ガイド」を読んだ

スクラム現場ガイドを読んだ。スクラムを始めて詰まっている事がそのまま出てきたり、このままだと良くないと気付ける内容があったりと、副題にもあるようにスクラムを始めたときに読むと、共感が沢山な書籍だった。

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

本書は30個の物語があり、特に早く行動するべきだと思った部分をまとめておく。

完成の定義を決める

完成の定義が決めきれずに進んでしまっていて、今もふわっとしている。決めるのが難しいと感じていたんだけど、なぜ難しいと感じていたのかが分かった。書籍では「ストーリーの定義」「スプリントの定義」のようにカテゴリ事に完成の定義を決めていてた。
勝手に共通の定義を作らないといけないと思っていたから難しかったんだと気づいた。完成の定義をブレインストーミングで決めていく方法も書かれていたので試してみたい。

「7章 完成を知る」より

ストーリーの分割は価値がある最小機能

スクラムを始めて、プロダクトバックログアイテムを小さく小さくと考えるあまり、TODOリストみたいになってる事があった。「あれ?なんか違うくない?」って気づいていたけど、答えは見つかってなかった。
書籍は目安として、以下のように書かれていた。

ユーザーがやりたいと思うアクションの最小のもの、あるいはビジネス価値がある最小の機能

TODOリストみたいになる事の違和感は正しかったと感じた。ストーリーもユーザー目線で分割する必要がある。チームメンバーが同じストーリを見たときに認識がブレず、計測できる範囲内であればいいと思った。

1点気になった事。ユーザーストーリーはエピック、テーマ、ストーリーに区別できる書かれていて、エピックは複数のテーマで、テーマは複数のストーリーで構成されるけれど、この親子関係をプロダクトバックログでどうやって管理するんだろう。
エピックやテーマはプロダクトバックログには入らずストーリーだけが入るのかな?

「12章 ストーリーやタスクを分割する」より

スプリントレビューは準備する

スプリントレビューは上手く出来てなくて、きちんとやらないとっと思っているので参考になる章だった。どういった準備をすると良いかが書かれていたのでマネてみようと思う。
しっかりとフィードバックが貰えるように準備をしよう。

「15章 スプリントレビュー」より

さいごに

どの章も参考になることが沢山あった。また、章の単位が分かりやすく「あれ?なんか上手くいかないぞ」と思ったときに、さっと対象の章を読み直せると思う。