私のケースの少し紹介:
より大きな製品の一部として、私のチームはDSL用の小さなIDEを実現するように求められます。この製品のユーザーは、コードで関数呼び出しを行うことができます。また、いくつかの便利な関数ライブラリを提供することも求められます。チームは、POと一緒に、IDEユーザーのさまざまなライブラリに関する特定の数のユーザーストーリーを壁に配置しました。それらの最初のストーリーを推定するとき、チームは関数呼び出しメカニズムが魅力的ではあるが完全に明白ではないタスクであると判断したため、そのユーザーストーリーの推定は単純な3からより危険な5に上がりました。
問題に来る:
次に、チームは他のライブラリに関するユーザーストーリー(実際には10のストーリー)に移動し、これらの2つの「関数呼び出しメカニズム」のことを各ユーザーストーリーに追加しました。これですぐに20ポイントの商品の合計ポイントがアップしました!チーム内の誰もが、各ユーザーストーリーはいつでも次のイテレーションのPOによってピックアップされる可能性があることを知っているので、1つのユーザーストーリーでその部分を分離するべきではありませんが、それらの20ポイントは非常に非現実的に感じられます。
私は解決策を提案しましたが、完全に満足していません:
「デザインストーリー」を作成し、面倒な2点を載せました。しかし、私たちがそれを実現して顧客に示すようになったとき、私たちはその話について彼らにとって本当に価値のあるものを示すことができませんでした!
ここでの問題は、孤立したユーザーストーリー(それらの間の依存関係なし)の原則を無視すべきかどうかです。
このような状況で、あなたは何をしますか?
(小さな脚注:提案に従って、この質問をstackoverflowから移動しました)