【IT168 技术文章】

    在以往的项目中，有这样的教训：

    1、PO确认的Production Backlog本身的Business Value并不高，但技术部门并没有仔细分析，或者认为不是我们的责任，在最后Demo的时候sprint的提交并没有得到认可。不管是谁的责任，整个team感到Frustrated

    2、Team并没有认真分析工作量评估，实际的完成时间大大高于评估时间（没有认真的分析技术风险，影响模块，整合测试时间）。

    为了避免这样的问题，我们在评估需求时一定进行如下关键节点的评估：

    1、必须讨论User Story的Business Value。有时PO只是为了增加市场机会，有时PO自己也没有想清楚。需要SM和Team去提出更多的问题去澄清。有一个例子：产品功能中要求不能在凌晨发送短信，但只有电力行业例外。PO提出了一个User Story：系统管理员可以定制每个用户何时可以发短信，认为是高优先级。我们（Scrum____ master和Team）在评估business Value时提出问题：电力行业客户是否是我们的目标市场？公司是否有资源做电力行业的销售？经过讨论后，PO的用意是来自marketing部门，他们不愿意放过任何一个可能的市场机会，但marketing也承认确实机会比较小。这样，这个User Story的优先级非常低。

    2、如何做Demo。这有助于比较彻底的了解需求

    3、什么是完成（done）的标准：倾向于每一个User Story单独做。这有助于进行工作量评估。

    4、进行工作量评估：必须经过所有Team成员的讨论。

    有一个用过的银行系统Use Story评估模板，见图片。