文章频道为您提供Leangoo实践,以及Scrum,敏捷,精益创业,产品创新等领域专业文章。

Sprint Backlog  8 个小贴士

创建一个好的Sprint Backlog 的8个小贴士

Sprint Backlog是Scrum 团队在当前Sprint必须完成的任务清单,根据Sprint backlog ,Scrum团队在Sprint的最后交付一个带有增量功能的软件。

创建Sprint Backlog发生在sprint计划会议的第二部分,每一个团队成员都需要参加。真正的重视这个过程是更好地了解Sprint中团队应做哪些工作,以及更好的做Sprint的计划的基础。尽管这样,许多团队仍然为这个事情挣扎。
我希望如下这些建议对他们有点帮助:

1.让每个队员都要参与这个过程。

2.讨论每一个用户故事应该如何实现。确定开发任务之前。

3.对于完成的标准要有明确的定义。

4.标识出所以需要完成的任务。

5.不要事先分配任务。

6.重新审视sprint的承诺。

7.不要使用过多的时间。

8. 在sprint过程中演化Sprint Backlog。

此文由Scrum中文网整理,转载请注明出处

leangoo_sprint

设置Sprint0是个好主意吗?

我在之前的帖子里曾写过对sprint进行编号除了用数字之外还有其他选择吗?今天这篇帖子我来说说一些团队给sprint编号时使用的的一个非常特殊的数字—0。

Sprint0这个概念在有些团队中变得越来越常见,所以我们很有必要来思考一下它到底是不是个好的提议。

首先,假设我们赞同sprint0存在的必要性。Sprint0通常被声明为必须的,因为在scrum项目开始前有许多事情要完成。例如,需要组建一个团队。这可能涉及到要招聘或调拨一些人到这个项目来。有时,也需要采购一些硬件或至少要安装一些软件。许多项目组也在努力说服别人,说他们需要在sprint0中编写初始backlog(即使仅仅是高级别的)。

设置spint0的一个最大的问题是,它产生了例外—有些sprint或sprint类型具有与众不同的特性。比如,在sprint结束时能得到潜在的可交付的成果这一scrum宗旨就被摒弃了。毕竟,如果sprint的目标是组建团队,那么他们怎么能得到潜在的可交付的东西呢?
Read more

用户故事

写好用户故事的10个技巧

用户故事可能是捕获产品功能的最流行的敏捷技术:使用用户故事很容易。但讲出有效的故事可能很难。以下十个技巧可以帮助您创建好的故事。
1. 用户第一
顾名思义,用户故事描述了客户或用户如何使用产品,它从用户的角度进行表达。另外,用户故事特别有助于捕捉特定的功能,例如搜索产品或进行预订。下图说明了用户,故事和产品功能(由圆圈表示)之间的关系。

1

如果你不知道谁是用户和客户,以及为什么他们会想要使用这个产品,那么你不应该写任何用户故事。首先进行必要的用户研究,例如通过观察和访问用户。否则,就有基于自己的想法和信念写出假想的故事的风险,而不是基于数据和经过验证的证据。
Read more

海报22副本

2016 Scrum联盟Scrum行业调查报告

2016年的Scrum联盟会员调查显示,曾经只用在软件开发领域的Scrum和敏捷实践,在IT行业之外也取得重大进展,并在非技术行业中也获得认可。这项调查结果反映了目前的一种趋势——各类公司都在使用Scrum和其他敏捷框架来进行创新和保持竞争力。

全球劳动力市场上的敏捷趋势

89%的受访者表示,在他们公司使用Scrum(或至少包含Scrun)作为实施敏捷的方法。(92%的受访者使用各种形式上的Scrum)。kanban是第二常见的,接下来就是Hybrid,然后是传统的瀑布模式。前三位的排名2015年是21%,在2016年已降至17%。
Read more

图1

反对迭代0:停止拖延,开始迭代

很多项目都不会一开始就完全就绪——例如,需要分配人员和准备工作。为了处理这些项目开始前的任务,很多团队使用了“迭代0”的做法。虽然理解其由来,但我仍然感到担心。以下是我的理由。

停止“迭代0”的三个理由:

首先,尽管很难相信,但绝大多数的项目都是可以立刻启动的。我所听过的所有声称需要在Scrum项目启动前完成的事项有:需要组建团队,包括调配人员到项目上或雇佣新人;需要获取或者设置硬件设备;需要写一个初始的产品待办列表(即使只是高度概要的)。然而现实情况是:诸如技术环境、初始产品待办列表之类的事项都可以在第一个迭代中完成(一个完全是正常的和传统模式的迭代一),同时至少还可以交付了某些潜在可发布产品增量。
Read more

Leangoo

故事点数是对工时的度量

尽管我尽了最大努力来澄清,但是仍然流传这样一种说法:故事点数是对复杂度的度量。这种说法是完全错误的。真相是,除非复杂度已经对完成用户故事的工作量造成影响,否则其复杂度并不重要。

让我举个例子。假设你和我一起观察离一栋建筑物的距离。你认为需要走5分钟,而我因为正拄着拐杖所以需要走10分钟。

Read more

2721018599879608912

放弃在每日站会上按成员逐个发言

很少有Scrum文献会说每日站会需要按团队成员逐个发言。然而大多数团队恰恰都是这样做的,但这可能不是最好的方式。

当每日站会是逐个团队成员进行的时候,团队成员会很容易丢掉所讨论的待办事项的上下文。例如,可能第一位团队成员正在处理前两个产品待办事项,第二位团队成员正在处理第二个和第五个产品待办事项,第三位团队成员也在处理其中这些待办事项中的一个,同时花费少量精力处理另一个无人的待办事项。

Read more

Scrum敏捷管理实践

是时候取消Sprint评审会议了吗?

Sprint评审会议长期以来一直是Scrum的一个很重要的部分,它是团队为迭代交付的产品增量获得反馈的一种机制。在Sprint评审会议上,产品负责人根据收到的反馈来决定接下来的Sprint的需求的优先级。

那么,到现在Sprint评审是否已经过时了呢?

十年前,差不多每个Scrum团队都是按照Sprint,Sprint,Sprint,Release(发布)这样的模式交付的,每个做几个迭代上线一次,极端情况是每个迭代都上线,很少听说在Sprint中间发布上线。

而现在,很多团队都在实践持续交付和持续发布,一天发布多次也是很普遍的。

我们设想一下,针对一个进行持续发布的团队,我们按照原来的思路进行Sprint Review的场景:
Read more

产品负责人职责

大型敏捷团队的首席产品负责人角色

在Scrum项目中,产品负责人可能是最有挑战性的角色之一。在所有项目中,产品负责人都需要把精力平均分配到对内和对外两个方面。

产品负责人对内的主要任务有:

  • 参与Sprint计划会议;
  • Sprint评审会议;
  • Sprint回顾会议和每日站会;
  • 管理产品Backlog;
  • 回答团队的问题;
  • 以及在整个Sprint过程中对团队保持在线

产品负责人对外的任务包括:

  • 与用户讨论需求;
  • 进行用户调查并分析结论;
  • 拜访客户;参加行业展会;
  • 管理干系人的期望;
  • 对产品Backlog进行优先级排序;
  • 确定产品定价;
  • 制定中长期产品战略;
  • 观察行业和市场发展趋势;
  • 进行竞品分析;
  • 等等。

Read more

封面图

产品经理的沟通策略

产品经理处于沟通枢纽的位置,工作中需要跟各种岗位的人打交道,比如:领导、开发、运营、客户、用户、合作伙伴…

图1

沟通能力是产品经理的一项重要技能,很大程度地决定了产品经理的工作能否顺利开展。

那么,产品经理应该采用什么样的沟通策略?

产品经理的沟通策略,形象点来说,就是:见人说人话,见鬼说鬼话。

产品经理跟不同角色的人沟通,要采用不同的沟通方式:
Read more