バックログの仮説にストーリーポイントを割り当てる

Question

Scrumをプロジェクト管理プラットフォームとしてしばらく使用してきましたが、今はLean UXおよび仮説主導の開発プラクティス。 ポーカープランニングを使用して、結果を出すために必要な作業を決定しています。

Barry O'reily'sproposition を使用して、バックログにユーザーストーリーと仮説の両方を含め、リーンUXによって提案されたアプローチJeff Gothelfすべての取り組みは、開発チームの努力。そのためには、ストーリーポイントを仮説に割り当てることもできる必要があります。

ポーカープランニングが比較に基づく測定であるとすると、ストーリーポイントを仮説の取り組みに割り当てるための適切なアプローチは何でしょうか？

PSリーンの概念から学んだことを基に、すべての開発努力をスプリントに移すことを決意しています。さらに、「#NoEstimates」の動き。

Ryathal · Accepted Answer

自分自身のプロセス内で定義を大幅に変更しない限り、ストーリーポイントまたはスクラムについて、ストーリーポイントを何かに割り当てることを不可能または困難にさえすることはありません。ストーリーポイントは複雑さに基づいた推定値であり、時間とのあいまいな関係のみが含まれます。ほとんどの場合、ストーリーポイントは最終的に時間ベースになり、任意のストーリーまたは問題への割り当てが容易になります。第二に、すべてのスプリントの終わりに出荷可能な製品を提供できるスプリントが何を意味するのかについての誤解があります。ストーリーとスプリントは、価値の単位を製品所有者に提供することを目的としています。これは、一般的に、すべてのストーリーの作業コードとして誤って解釈されます。仮説主導の開発の場合、はいまたはいいえは貴重な部分です。ストーリーは、はい/いいえを取得する方法と、はい/いいえで何をするかに向かって機能する必要があります。仮説をテストするまでは、仮説を完全に作成して実装するためにストーリーを記述または推定する必要はありません。その時点で、合理的な推定を提供するための十分な洞察が得られるはずです。他のストーリーの出力を持つストーリーを作成することも可能で便利です。

別の要件を収集し、たくさんのことを書いてもらい、それを壁を越えて開発チームに投げ込もうとするという、よくある落とし穴にいるようです。これは壊すのが難しい滝の考え方です。好ましい代替案は、アイデアを取り、それをストーリーと要件に変えるのを助けるために、開発チームの一部が関与するストーリーを用意することです。既に多くのことをしている場合、最善の解決策は、それを論理的なストーリーの内訳（最初のパスとして）に書き込み、バックログのグルーミング時間を使用して、最初のストーリーを再構成して具体化することです。

製品の所有者がこれらのアイテムに優先順位を付ける方法については、機能/エピックス/ストーリーとして記述されると、簡単になります。仮説Aが追求する価値があるかどうかを知ることは、新機能Bやバグ修正Cよりも多かれ少なかれ重要であるという単純な質問になります。仮説Dが、次のテストの設計がどれほど難しいかがまったくわからない場合は、ストーリーを作成しますそれを見つけて優先順位を付けます。スプリント計画プロセスに「何を知りたいか」を追加することは、実際には開発作業ではないが、しばしばより有用である多くの貴重なユーザーストーリーを取得するのに役立つ方法です。

Daniel · Answer

私は仮説主導の開発の専門家ではありませんが、ある程度の知識があります。ここに私が検討するいくつかの事柄があります：

仮説の完全な実現には、さまざまな時間がかかる場合があります。これは、スプリントのタイムボックスでは問題が発生する可能性がありますが、実験にはそれを証明するための時間が必要です。もちろん、小規模な実験と真に継続的な展開サイクルでこれを軽減できますが、それを認めるのは少なくともリスクです。
プロセスは本質的にオープンエンドです。条件が満たされるまで、作業が完了したことはわかりません。「サインインフォームの複雑さを軽減することで、煩わしさが減り、サインアップの完了率が上がると考えています。開始されたサインアップの完了率が10から増加した場合、それが成功したことがわかります。％から30％。」これで作業が完了し、次の期間で23％に増加します。あなたは前向きな進歩を遂げましたが、あなたはそこに到達しませんでした。十分いいですか？戻ってプロセスをさらに簡略化して、最後の7％が得られるかどうかを確認しますか？これは、チームや組織が非常に上手になるために必要な会話です。
他のオープンエンドのアイテムと同様に、利益を得ることなく仕事を注ぎ続けるリスクがあります。 XPのスパイクのようなプラクティスには、同じ問題があり、ポイントではなくタスクベースのタイムボックスで対処します。タスクベースのタイムボックスは、特定の時間に費やす時間を実際に定義するだけです再グループ化して、もっと時間を費やす価値があるかどうかを判断する前に問題が発生します。したがって、上記の例を使用すると、ページの簡略化に16時間を費やしても大丈夫だと判断する場合があります。その後、結果を確認し、より多くの時間を費やす価値があるかどうかを確認します。
最後の考え：フレーミング作業の1つの方法だけに過度にコミットしないでください。仮説主導の開発のアイデアは本当に強力です。ユーザーストーリーも同様です。他の多くの作業方法も同様です。私が協力したすべてのチームは、1つのアプローチだけに固執するのではなく、その特定の取り組みに最も適したフレーミングを選択した方がよいでしょう。