<story><title>Defense against the dark art of estimation bargaining (2014)</title><url>http://www.monkeyandcrow.com/blog/estimation_bargaining/</url></story><parent_chain><item><author>Tade0</author><text>&amp;gt; Bargain scope, not time&lt;p&gt;I&amp;#x27;ve started applying this and it&amp;#x27;s amazing how well this works.&lt;p&gt;Of course sometimes it&amp;#x27;s just not possible to reduce the scope any further, but the key point is that the stakeholders just want something, anything and as soon as possible at that.&lt;p&gt;You give them that and suddenly there&amp;#x27;s much less pressure and you can focus on delivering the rest, or sometimes dropping it entirely because in hindsight it wasn&amp;#x27;t that important.&lt;p&gt;There&amp;#x27;s a similar phenomenon occuring when playing planning poker - often the estimate is not what anyone wanted, but the one that the most could agree on, which is usually way off. I thought of solving this by having a single transferable vote, but I hadn&amp;#x27;t had a chance to play planning poker for over a year now, so I have no data on its effectiveness.</text></item></parent_chain><comment><author>eastbayjake</author><text>When I play the tech lead role, I try to view my job as the business&amp;#x2F;PO&amp;#x27;s &amp;quot;counselor in the art of the possible.&amp;quot; Two things that help in estimation:&lt;p&gt;1. Help your development team make explicit the assumptions in their estimate. This is part of bargaining scope instead of time -- when you make explicit that your estimate includes e.g., authentication and responsive design and reusable component development, your business stakeholders will sometimes say &amp;quot;No no no we don&amp;#x27;t need those things now, we only need X and Y&amp;quot; and suddenly the team has a much more feasible effort in front of them.&lt;p&gt;2. Don&amp;#x27;t argue beyond a certain point, occasionally resolve disputes by giving the story to the person with the lowest estimate. Sometimes it&amp;#x27;s a learning experience for the developer who underestimated. Sometimes it&amp;#x27;s a learning experience for the rest of team that overestimated. I have taken 1 point stories that the rest of the team swore would be an 8 point story, then used it as an opportunity to pair program with one of my developers to show my approach. (If the business wants an unstyled link to open an email message to your support address, that&amp;#x27;s not a reflection of your skill as a developer -- you don&amp;#x27;t need to solve for the full-function feedback popup modal with input validations and error states, it&amp;#x27;s work you can do as iterative enhancements later, if ever at all.)</text></comment>
<story><title>Defense against the dark art of estimation bargaining (2014)</title><url>http://www.monkeyandcrow.com/blog/estimation_bargaining/</url></story><parent_chain><item><author>Tade0</author><text>&amp;gt; Bargain scope, not time&lt;p&gt;I&amp;#x27;ve started applying this and it&amp;#x27;s amazing how well this works.&lt;p&gt;Of course sometimes it&amp;#x27;s just not possible to reduce the scope any further, but the key point is that the stakeholders just want something, anything and as soon as possible at that.&lt;p&gt;You give them that and suddenly there&amp;#x27;s much less pressure and you can focus on delivering the rest, or sometimes dropping it entirely because in hindsight it wasn&amp;#x27;t that important.&lt;p&gt;There&amp;#x27;s a similar phenomenon occuring when playing planning poker - often the estimate is not what anyone wanted, but the one that the most could agree on, which is usually way off. I thought of solving this by having a single transferable vote, but I hadn&amp;#x27;t had a chance to play planning poker for over a year now, so I have no data on its effectiveness.</text></item></parent_chain><comment><author>mathattack</author><text>This is also a good way to understand the priorities of the buyer or decision maker. Forcing someone to stack rank priorities in the scope negotiation separates must haves from nice to haves. This is even more important when you deal with Requirements By Committee.</text></comment>