管理–不只是维护– a Product Backlog “产品人员-产品经理,产品设计师,UX设计人员,UX研究人员,业务分析师,开发人员,制造商和企业家 March 03 2017 真正 产品开发,产品计划,技能,策略, 注意产品 介意产品有限公司 1146 产品管理 4.584

管理–不只是维护– a Product Backlog

通过 ON

或产品所有者可以掌握Scrum的三种方式

对于Justinmind产品开发团队来说,2016年是重要的一年。我们每个月左右发布一次新功能,解决了错误修复并升级了我们的软件(交互式原型工具)的可用性。事后看来,这是令人兴奋的,但是如此激烈的活动给产品所有者带来了挑战:积压的订单可能会变得松散,用户故事之间的优先级会变得复杂。无法掌握不断增长的积压可能会导致产品不稳定。我认为是时候开始更有效地管理Justinmind的产品积压了。

积压整理的挑战

从理论上讲,产品待办事项与冲刺之间的关系很简单:您可以在产品待办事项中确定用户故事的优先级,然后在新的冲刺出现时,将最高优先级拉入冲刺,并让团队开始工作。

但实际上,存在复杂的因素。在较小的团队中,很难在两周的冲刺中完成您想要或需要做的所有事情–而且不可能每两周对每项任务进行详细的成本效益分析。最明显的是,有时候感觉就像Scrum方法创建了不平衡的sprint工作流程: 将所有产品堆积在待办事项中,就不可能对主要产品的更改进行细微调整以使其具有优先级。如果用户故事的类别之间没有分隔,则产品所有者可能会开始避免沉重的新功能故事,而只专注于悬而未决的错误修复,反之亦然。

在Justinmind,我们觉得我们正在将苹果与橙子进行比较,最终遇到了问题,因此我们探索了改善积压管理的方法

少量积压,组织更多

作为产品负责人,我想出了一个用于管理积压活动的系统,该系统既足够敏捷以供小型产品团队使用,又足够严谨和客观,可以定期发布大型功能。我的系统围绕使用颜色编码的JIRA过滤器将用户故事分类到相关的组中进行,该过滤器允许按类别中的优先级过滤用户故事。

贾斯汀敏德积压样机
模拟贾斯汀敏德未过滤积压的图像

说我想在待办事项中管理UX改进案例。我单击主待办事项顶部的蓝色选项卡,所有其他故事都被过滤掉。现在,优先排序这些故事变得更加容易,因为将“喜欢”与“喜欢”进行了比较。在继续进行下一个小型积压工作之前,我可以通过将优先级功能放在顶部来管理此小型积压工作。

Justinmind UX改进样机
模拟了“ UX改进”过滤器的图像。

在每个过滤的部分中,我们使用评分系统来确定任务难度。像任何计分系统一样,它必须快速实施(没有人愿意花更多的时间对故事进行计分)并且对产品利益相关者透明。 Scrum扑克为我们工作:团队根据计分制估算待办事项中的每个任务–1个代表史诗,最多16个–使用个性化的Scrum卡,这是一种轻松而集中的方法,可鼓励诚实的讨论和更有效的故事估计。

贾斯汀敏德冲刺样机
模拟Justinmind的Sprint图片。您可以在右侧看到每个故事的积分评估

当需要建立一个Sprint时,我会进入每个微型待办事项列表,并收集前两个或三个用户故事,并将它们添加到Sprint中。 Justinmind的冲刺通常包含最多35分的故事:根据过去的经验和团队规模,这对我们来说是一个现实的冲刺工作量。较大的团队或具有不同能力的团队将具有不同的积分能力。

拆分积压,拆分路线图

Justinmind的产品团队非常小,因此上述的迷你积压系统现在对我们来说很好用。但是,在拥有更多用户故事的更大的Scrum团队中,可以将小型待办事项列表系统扩展为将您的产品待办事项分成两部分。一方面是正在进行的任务,包括错误和功能改进,另一方面是诸如功能之类的新内容。应该使用计分系统对重要的新功能和产品线进行详细优先排序,而正在进行的任务(可能是重复的和熟悉的范围)可以更宽松地处理,而不能进行细致的分析。这使产品所有者可以腾出时间专注于大型新任务,同时仍能主动管理故事。

对于某些敏捷团队而言,将用户故事分成两个单独的路线图可能意味着 产品积压经理和产品负责人说,将产品负责人的职责划分为两个新角色正如安德鲁·佩特罗(Andrew Petro)所说。尽管这不是强制性的,但这是产品积压开始蔓延的另一种解决方案。

速度追踪

产品积压管理的另一种选择是跟踪团队的速度或在sprint中完成多少工作。一旦产品所有者跟踪了几个冲刺的速度并收集了一些平均值,就可以使用该数据来预测可以向将来的冲刺中添加多少个故事和类型。

计算速度很简单。在一个为期两周的冲刺中,产品团队传递的故事总值为35,使该冲刺的速度为35。下一个冲刺他们传递的故事值为20。因此,平均速度为27.5。您团队中计入故事点的任何内容(包括错误和调整)都可能影响速度估算;抱歉,不完整的故事不计入速度。

对于我们的团队,我们跟踪的速度是每月大约35个用户故事点。每次建立冲刺时,我都会添加由Scrum团队在Scrum扑克中评估过的故事,并尽量不超过35分。我会不时地查看速度平均值,以确保我们按预期工作。

这种长期的速度跟踪功能使产品经理可以估算他们需要花费多长时间来完成当前的积压工作,并凭经验向团队和利益相关者证明这一估算的合理性。

关于速度跟踪的重要方面是,您做得越多越好。有关团队能力和绩效的数据越多,积压管理将越准确。

主动积压管理:好处

小型待办事项可以帮助您保持井井有条,因为它们可以让您在确定任务优先级时进行比较,并且可以帮助您在每个冲刺中保持活动的多样化。此外,如果Scrum团队在建立Sprint之前没有评估每个故事的难度,这不是世界末日,因为它们已经按优先级进行了组织。

从更深层次来看,我们发现将主要的待办事项划分为几个部分,从而可以使sprint工作流程更加简化,并提高Scrum的效率。最重要的是,我们最终获得了更加平衡的开发路线图,并最终获得了更好的产品。