スクラム：ユーザーストーリーのデザイン/ UXが実装と同じスプリントで発生しても問題ありませんか

私は現在、スプリント中（2週間）で、特定のユーザーストーリーの要件とUXを定義することをデザイナーに課しています。

同じスプリントで、私はこのデザインを実装します。スプリントの計画中、私はこの未定義のユーザーストーリーがどのくらいの時間を要するかについて、かなりの推測をしなければなりませんでした。

今日、ようやくデザインを受け取りました。残念ながら、設計は不完全で曖昧であり、設計よりもクライアントの要件に似ています。ただし、このことから、まだ十分に見積もっていないことがわかります。

さらに悪いことに、これは初めてではありません。最後のスプリントでは、まったく同じことが起こりました。私はそれを振り返ってフラグを立てましたが、スクラムマスターは「それはあなたのための単なる開発だ」と言うのではなく、これを解決する方法の答えがありませんでした。皮肉なことに、バーンダウンが目標に達していない場合、彼はイライラします...

今、私は彼の仕事を成し遂げるためにデザイナーに尋ねる/協力する必要があります。私は他のすべてのタスクを完了しているので、これは私を我慢するでしょう。

だから私の質問は

スプリント計画で依存関係をどのように処理しますか？

理想的には、開発以外の依存関係はスプリント計画の前に処理されるため、努力を見積もるバックログ項目を適切に定義できます。

しかし、それが「あなたのためのただの開発」の最後のスプリントだった場合、それはおそらくこのスプリントのためのただの開発になるだろう。したがって、そこで実際に見積もりを増やし、次に同様の状態にある次のタスクを行う必要があります。これは正当な判断を下すものではなく、そのようにそれをやってしまうのは間違いでしょう。

それが行うことは、推定するための比較的堅実な設計なしの推定の不確実性を示しています。おそらく、これにより、マネージャは製品のバックログ項目が適切に定義されていることを確認できます。しかし、最悪の場合、それはあなたの背中をカバーします。仕事が予算不足になったときに文句を言う人はいません。

しかし、あなたはそれをしなかった、そして今あなたの質問は...

どうすればスプリントにアプローチできますか？

プロジェクト管理ツールとしてのスクラムの主な目的は、問題を早期に特定することです。それをあなたの管理者にフラグを立てて、彼らにスプリントをどうするかを決めさせてください。彼らがあなたを責めようとする場合は、謙虚になり、公正であると本当に信じていなくても、同じ問題を回避するために、将来同じような状況に取り組むことを提案する方法を尋ねてください。

結局のところ、これらはプロジェクト管理の問題であり、自分のバブルの中でそれらを解決しようとすると、失敗するように設定されます。そして、あなたがそうするとき、あなたはそれをあなたにフラグを立てたときに問題を解決することに失敗したマネージャーではなくあなたに落ちるのであなたは怒るでしょう。

まず、ストーリー/タスク間の依存関係と、ストーリー/タスクの範囲/努力の不確実性には大きな違いがあります。

依存関係は、依存するタスク/ストーリーに、依存するタスク/ストーリーよりも低い優先度を与えることで処理されます。また、他のタスク/ストーリーが完了する前に開始できないという注釈も可能です。

不確実性は、ストーリーで行う必要がある作業を明確にすることにより、計画会議で対処する必要があります。不確実性を十分に取り除くことができない場合、ストーリーは「準備完了の定義」を満たしていない可能性が高く、スプリントに受け入れられません。
何らかの理由で、ストーリーが本当にスプリントに入る必要がある場合、残された唯一の選択肢は、リスクバッファーを推定に追加することです。

現在のスプリントで、ストーリーに取り組むことができない場合は、次の毎日のミーティングでそのことを報告し、チームの全体的なスプリントの目標に到達するために可能なあらゆる作業を実行してください。また、ブロックされているものとして、何によってストーリーに注釈を付けることもできます。
スプリントが開始された後、スプリントに新しいタスクを追加することは原則として不可能です。
また、タスクが見積もりよりも多くの作業であることが判明した場合は、見積もりを変更しませんが、タスクの進捗状況と残りの作業を正確に報告します。

結局、スクラムでは、何かを提供することを約束するのはチームです。その約束をすることができない場合、それはチーム全体の失敗であり、チーム内の個人の失敗ではありません。

スプリントの計画中に、この未定義のユーザーストーリーにかかる時間については、かなりの推測をしなければなりませんでした。

それはあなたがした間違いです。誰もチームにスプリントのタスクを強制することはできません。少なくともワイヤフレームがなければ（たとえば）、タスクをスプリントで見積もり、承認できないことを伝えるのはあなたの仕事です。あなたのスクラムマスターは実際にはプロジェクトマネージャーであり、事態を悪化させるだけのようです。

（有効なビジネス上の理由から）スプリント内で達成する必要がある場合、そのようなタスクにどのようにアプローチしますか？さて、最初にデザインの期限を設定する必要があります。そうしないと、それを実装することができなくなります。たとえば、ストーリーは受け入れられますが、デザインは最初の1週間以内に配信され、2週間以内に実装されます。次に、設計者と緊密に連携して、スプリントに実装できるようにする必要があります。スクラムは機能横断的なチームを想定しており、デザイナーと一緒に作業を整理するのはあなた次第です。そうは言っても、スプリントでタスクを受け入れる場合は、チームが決定します-スプリント内で完了するように作業を管理し、関連するリスクを管理するのはチームの責任です。他の人が仕事を終えるのを待って、仕事を終わらせてはいけません。組織のより大きな機能障害を明らかにしようとしている可能性があります。

デザインに関するタスクはストーリーとして表現されていますか？また、チームの定義は何ですか？

• ストーリーができました
• 物語ができた

各ストーリーには独自の要件と受け入れ条件があるはずですが、すべてのストーリーに適用できる一連のルールを作成することをお勧めします。たとえば、ストーリーは、次の場合にのみ準備されます（エンドツーエンドのアーキテクチャスタディが終了し、デザインが利用可能であり、ストーリーがチームによって推定されている場合）。受け入れの最小条件は次のとおりです。自動テストが行​​われ、OKであり、テストスーツに統合され、コードレビューが行われます。

ストーリーの準備ができていない場合は、スプリントに組み込まないでください。受け入れの条件が満たされない場合、それは終了しません。

あなたのケースでは、チームは準備ができているために、開発ストーリーには完全なデザイン（少なくともワイヤーフレーム、これを自分の現実に合わせて調整する）が必要であると決めることができます。その場合、同じスプリントで設計と開発を処理することはできません。チームは、UX /デザインストーリーがワイヤフレームデザインを最低限に生成するように決定することもできます。そうでない場合、ストーリーは受け入れられないため、それに依存するストーリーを開始できません。

準備ができているという強力なルールを持つことは良いことだとマネージャーに簡単に納得させる必要があります。スプリント中に複雑さを再評価することは悪い習慣です。それは、チームの速度が不確実であり、マネージャーとして、彼らがチームの仕事と将来について悪いビジョンを持っていることを意味します。

スプリントは通常、ストーリーが明確になったときに開始されます。この段階で、プロダクトバックログが確立され、優先順位が付けられます。あなたがデザインを持たずに始めた場合、デザインなしで何ができるのか、そして何ができないのかは明らかだったはずです...

設計がクライアントとPOの間で「急上昇」している間に即興する必要がある場合、POは新機能が現れたらすぐにチームにチームに通知する必要があります。これがスクラムの「柔軟性」の意味です。状況。開発チーム、スクラムマスター、およびプロダクトオーナーは恒久的に通信する必要があります。そうしないと、変更に対するリアルタイムの反応はありません。

もう少しトレーニングをしても害はありません...おそらく、デザイナーと一緒に作業することは、あなたがいくつかの新しいUXスキルを身につける機会になるでしょうか？...それは、ガラスが半分空ではなく半分になっていることを観察しています:)）