スクラムスタンドアップでは、昨日行われたことの議論は、ボード上のタスクまたは実行されたすべての作業に限定されるべきですか?


10

私は、毎日のスタンドアップでのスクラムルールは、チームは昨日何をしたか、今日何をしているか、そしてそれらを妨げるものについてのみ話すべきだと言っていることを知っています。他には何もありません。しかし問題は、開発者が1日を自分のタスクに関係のない作業に費やし、それについてスタンドアップで話し合うことです。彼らが昨日やったことです!

私の経験では、ボード上のタスクについて話し、スタンドアップに焦点を合わせ、全員のタスクに焦点を合わせ続け、見積もりを確認してレコードを毎日追跡する方がより効果的であることがわかりました。

ディスカッションをボード上のタスクに限定することは有効ですか?


1
開発者がタスクに取り組んでいない丸一日を費やすことは、言及されなければ見えない問題になる可能性がありますか?
RemcoGerlich 2016年

誰もが30秒間話し、前に行ったことを話します。どれだけ集中したいですか?見積もりを確認しません。タスクを次の担当者(レビュー担当者またはテスター)に渡すときに追跡します。
gnasher729 2016年

回答:


5

毎日のスタンドアップに関するスクラムガイドの内容に従って、議論のための3つの質問は次のとおりです。

  • 開発チームがスプリントの目標を達成するのを助けた昨日は何をしましたか?
  • 開発チームがスプリントの目標を達成するために今日私は何をしますか?
  • 私または開発チームがスプリントの目標を達成するのを妨げる障害はありますか?

すべての質問はスプリント目標に焦点を当てており、ボードにあるタスクではありません。繰り返しになりますが、スクラムガイドに従って、スプリント目標はスプリント計画で作成され、「製品バックログの実装を通じてスプリント内で満たされる目標を定義し、開発チームがインクリメント"。

開発チームが行うすべてのことは、理想的には、チームがスプリント目標に向けて前進するのに役立つはずです。これらは、ボード上にない計画外のアクティビティである可能性があります。または、考慮および推定された可能性はあるが、ボード上のアイテムよりも低いレベルである可能性があります。

私はあなたのチームに彼らが昨日やったことすべてについて話させてくれると思います。チームがスプリントの目標を達成するのに役立たないことについて話している場合、特にチームをスプリントの目標の達成に近づけるような他のことができた場合、誰かがこれを提起する必要があります。

1つの例外は、個人が複数のスクラムチームをサポートしている場合です。会議では、彼らはおそらく彼らが昨日やったことすべてについて話すべきではなく、現在スタンドアップをしているチームをサポートするために彼らがしたことについて話すべきです。

スプリントレトロスペクティブはチームで、この問題について話をする絶好の機会です。考慮すべき多くの質問があります:

  • チームはスプリントゴールに関連する項目について十分な準備ができていませんか?
  • 予定外の作業が多すぎませんか?
  • 計画外の作業はどこから行われ、誰がそれを承認しますか?
  • なぜ人々はボードにないものに取り組んでいるのですか?
  • ボード上の項目に行う作業をより簡単に結び付けるために、ボードに詳細を表示する必要がありますか?

2
「Sprint Goal」の問題は、あいまいで希望に満ちたものです。実際には、スプリントの目標==ボード上のタスクを完了します。あなたが取り組んだことがそこにないのであれば、それがあるべきか、そうでないべきか
Ewan

1
@Ewan顧客から電話があり、ライブソフトウェアがクラッシュし、ログとバグレポートがあることがわかりました。現時点で理事会にいない場合でも、そのレポートをすぐにトリアージするために時間をかけることが重要です。スコープに入れられたり、バックログに入れられたりする可能性がありますが、それは昨日やったことであり、昼食後までボブの問題を解決できなかったのかもしれません。私は盲目的にその仕事をすべきではありませんが、このスプリントに引き込まれない限り、誰もそれをボードに置くことはおそらくないでしょう。他の例も考えられます。
トーマス・オーエンス

1
ボードに「ライブバグのトリアージ」チケットを追加して、完了としてマークする必要があります。その後、スプリントの最後に、確かに言うことができます。「このスプリントは、ユーザーエラーを調べるためにX時間を費やしました。それが私たちが遅れている理由です。私たちはヘルプデスクをよりよく訓練する必要があります」そうでなければ、あなたはスプリントで何も成し遂げられず、首相はチームからの言い訳をしているだけです。肩をすくめる '
ユアン

1
@Ewan信じられないほど不必要だと思います。チケットを書くのに一日を費やしたくない。プロセスで仕事を終わらせ、トリアージに95分ではなく90分のトリアージを行ってから、チケットをトリアージしたと言ったチケットを入れる必要があります。特に、複数のチケットをトリアージする必要がある場合。振り返って物事を議論するためにチケットは必要ありません。電子ツールを使用している場合は、スプリントでチームが変更したチケットを検索して、トリアージすることがたくさんあるかどうかを確認できます-伝聞はありません。
Thomas Owens

1
スクラムマスター/午後/会社までの場合のレポートのレベル。その日のすべての作業をカバーするために、1つの「トリガーバグ」チケットを作成するだけです。しかし重要なことは、あなたがそれをSPRINTの一部として記録することです。他のいくつかの測定基準で考慮されていると仮定しないでください
Ewan

0

いいえ、あなたは昨日あなたがしたことについて話すべきです。

ボード上にない場合は、次のいずれかを実行する必要があります。

  • ボードに置いて
  • それをやめる
  • またはチームを変更します。

最も一般的なのは、計画外の緊急作業で言うと、カードを書いてボードに貼り付けることです。これにより、スプリントの最後に速度を測定し、スプリントの目標が達成されなかった理由を説明できます。

スプリントにないものに取り組んでいるチームメンバーは、アジャイル導入が失敗する主な理由の1つであると私は考えています。ほとんどの場合、これは別のプロジェクトのライブの問題を修正するために転用された開発者です。

スプリントのもう1つの厄介なことは、「PMが他のプロジェクトの会議について話している」ことです。私の見解では、PMはスクラムチームの一部ではなく、「製品所有者」のスクラムの役割を果たし、進行状況を報告するのではなく、質問に答えます。


3
計画外の作業などがあります。誰かのブロックを解除したり、ボード上にある他のタスクを実行したりする必要がありますが、ボード上ではありません。多くの場合、ボードに配置するよりも実行する方が速い場合があります。それをどう処理するかを議論するのはチーム次第です。私の現在のチームにはルールがあります。本番環境またはQA環境にデプロイされたもの、または2時間かかるタスクはすべてボード上で行われます。話し合われているが、基準に合わないためにボードを作成しない、発生する必要があるより短いタスクがまだ時々あります。
Thomas Owens

@ユアン、それについて詳しく教えていただけますか?スプリントにない場合、ライブバグの修正は誰が担当しますか?プロジェクトオーナーはどのようにして同時にプロジェクトマネージャーになれますか?(つまり、彼、または彼が両方の役割を両立させていることを意味します)
デニス

明確にするために編集
Ewan

@Dennis:プロジェクトマネージャーはスクラムの役割ではありません。
RemcoGerlich 2016年

@Ewan、ありがとう。これは答えに必須ではありませんが、私は興味があります-「他のプロジェクトの会議について話しているPM」、これはどのように機能しますか?PMはプロジェクトXについて会議に参加しますが、Yについて話しますか?これを視覚化するのに苦労します。これはどのように/なぜ可能ですか?彼らがやって来て、本質的にうわさ話を始めたり、話題から外れたりしているのでしょうか、それとも、非即時の会議固有の目標やニーズについて話し合うより深い理由がありますか?私は「ちょっと聞いてよかったけど、私はプロジェクトYの一部ではありません...そこで知識/経験はありません。Xに戻ることはできますか?」
Dennis
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.