Testers and developers estimate story points together. The velocity of a sprint is always a combined effort. QA / testers cannot have their separate velocity calculations. That is fundamentally wrong. If you have 3 dev and 2 testers and you inclue the testers capacity and relate it to your output then the productivity will always show low. Testers take part in test case design, defect management and testing which is not directly attributed to Development. You can have efforts tracked against each of these testing tasks but cannot assign velocity points.
The solution is never black and white as each sprint may contain stories that require testing and others that dont. There is no problem in Agile of apportioning a tester for example; for 50% of their time during a sprint and 20% in the next sprint. There is no sense in trying to apportion a tester 100% of their time to a sprint and trying to justify it. Time management is the key.
First answer for velocity, than my personal insight about testers in scrum non cross functional team and early days of every sprint.
I see there inconsistency. If team is not cross functional you distinguish testers and developers. In this case you must distinguish them also in velocity calculation. If the team is not cross functional testers don’t really increase your velocity. Your velocity will be max of what developers can implement but no more than what testers can test (if everything must be tested).
Talk to your scrum master, otherwise there will always be problems with velocity and estimation.
Now as for testers and early days of sprint. I work as tester in not cross functional team with 5 devs, so this answer may be bit personal. You could solve this in two ways: a)change work organization by adding separate test sprint or b) change the way testers work.
In a) you crate separate testing sprint. It can happen in parallel to devs sprint (just shifted those few days) or you can make it happen once every two or three dev sprints. I have heard about this solutions but I had never worked this way.
In b) you must ask testers to review their approach to testing activities. Maybe it depends on practices and tools you use, or process you follow but how can they have nothing to do in this early days? As I mentioned before I work as tester with 5 developers in not cross functional team. If I would wait with my work until developer ends his task, I would never test all features in given sprint. Unless your testers perform only exploratory testing they should have things to do before feature is released to test environment. There are some activities that can be done (or must be done) before tester gets feature/code into his hands. The following is what I do before features are released to test environment: - go through requirements for features to be implemented - design test scripts (high level design) - prepare draft test cases - go through possible test data (if change that is being implemented is manipulating data in the system you need to make snapshot of this data, to compare it later with what given feature will do to this data) - wrap up everything in test suites - communicate with developer as feature is being developed - this way you can get better understanding of implemented solution (instead of asking when he has his mind already on other feature) - you can make any necessary changes to test cases as feature evolves
Then when feature is complete you: - flesh out test cases with any details that not known to you earlier (it is trivial, but button name can change, or some additional step in wizard appears) - perform tests - rise issues . Actually I find my self to spend more time on first part (designing tests, and preparing test scripts in appropriate tool) than actually performing those tests.
If they to all they can right away instead of waiting for code to be released to test environment it should help with this initial gap and it will minimize risk of testers not finishing their activities before end of sprint.
Of course there will always be less for testers to do in the beginning and more in the end, but you can try to minimize this difference. And even when above still leaves them lots of time to waste at the beginning you can give them no coding involved tasks. Some configuration, some maintenance, documentation update, other.
Sounds to me like your system is working, just not as well as you'd like. Is this a paid project? If it is, you could make pay be a meritocracy. Pay people based on how much of the work they get done. This would encourage cross discipline work. Although, it might also encourage people to work on pieces that weren't theirs to begin with, or internal sabotage.
Obviously, you'd have to be on the lookout for people trying to game the system, but it might work. Surely testers wouldn't want to earn half of what devs do.
Make the testers pair-program as passive peers. If they have nothing to test, at least they can watch out for bugs on the field. When they have something to test, in the second part of the week, they move to the functionality/"user story compliance" level of testing. This way, you have both groups productive, and basically the testers "comb" the code as it goes on.
This might be slightly off what you were asking, but here it goes:
I really don't like using velocity as a measure of how much work to do in the next sprint/iteration. To me velocity is more of a tool for projections.
The team lead/project manager/scrum master can look at the average velocity of the last few iterations and have a fairly good trend line to project the end of the project.
The team should be building iterations by commitment as a team. Keep picking stories until the iteration has a good amount of work that the team will commit to complete. It's your responsibility as a team to make sure you aren't slacking by picking to few and not over committing by picking to many. Different skill levels and specialties work themselves out as the team commits to the iteration.
Under this model, everything balances out. The team has a reasonable work load to accomplish and the project manager has a commitment for completion.
FogBugz uses EBS (Evidence Based Scheduling) to create a probability curve of when you will ship a given project based on existing performance data and estimates.
I guess you could do the same thing with this, just you would need to enter for the testers: "Browsing Internet waiting for developers (1 week)"
Here is what we do. When we add up capacity and tasks we add them up together and separately. That way we know that we have not exceeded total time for each group. (I know that is not truly scrum, but we have QA folks that don't program and so, to maximize our resources, they end up testing and we (the developers) end up deving.)
The second think we do is we really focus on working in slices. We try to pick tasks to get done first that can go to the QA folks fast. The trick to this is that you have to focus on getting the least testable amount done and moved to the testers. If you try to get a whole "feature" done then you are missing the point. While they wait for us they usually put together test plans.
It is still a work in progress for us, but that is how we try to do it.
Since Agile development is about transparency and accountability it sounds like the testers should have assigned tasks that account for their velocity. Even if that means they have a task for surfing the web waiting for testing (though I would think they would be better served developing test plans for the dev team's tasks). This will show the inefficiencies in your organization which isn't popular but that is what Agile is all about. The bad part of that is that your testers may be penalized for something that is a organizational issue.
The company I worked for had two separate (dev and qa) teams with two different iteration cycles. The qa cycle was offset by a week. That unfortunatey led to complexity when it came to task acceptance, since a product wasn't really ready for release until the end of the qa's iteration. That isn't a properly integrated team but neither is yours from the sound of it. Unfortunately the qa team never really followed scrum practices (No real planning, stand up, or retrospective) so I can't really tell if that is a good solution or not.
发布评论
评论（9）
测试人员和开发人员一起评估故事点。 冲刺的速度始终需要共同努力。 QA/测试人员无法进行单独的速度计算。 这是根本错误的。
如果您有 3 名开发人员和 2 名测试人员，并且您将测试人员的能力包括在内并将其与您的输出相关联，那么生产力将始终显示较低。 测试人员参与测试用例设计、缺陷管理和测试，这些不直接归属于开发。 您可以跟踪每个测试任务的工作量，但无法分配速度点。
Testers and developers estimate story points together. The velocity of a sprint is always a combined effort. QA / testers cannot have their separate velocity calculations. That is fundamentally wrong.
If you have 3 dev and 2 testers and you inclue the testers capacity and relate it to your output then the productivity will always show low. Testers take part in test case design, defect management and testing which is not directly attributed to Development. You can have efforts tracked against each of these testing tasks but cannot assign velocity points.
解决方案从来都不是黑白分明的，因为每个冲刺可能包含需要测试的故事和其他不需要测试的故事。 例如，在敏捷中分配测试人员是没有问题的； 在一个冲刺期间花费 50% 的时间，在下一个冲刺期间花费 20% 的时间。
试图将测试人员 100% 的时间分配给冲刺并试图证明其合理性是没有意义的。 时间管理是关键。
The solution is never black and white as each sprint may contain stories that require testing and others that dont. There is no problem in Agile of apportioning a tester for example; for 50% of their time during a sprint and 20% in the next sprint.
There is no sense in trying to apportion a tester 100% of their time to a sprint and trying to justify it. Time management is the key.
关于速度的第一个答案，是我对 Scrum 非跨职能团队中的测试人员以及每个冲刺早期的个人见解。
我看到其中存在不一致之处。 如果团队不是跨职能的，那么您可以区分测试人员和开发人员。 在这种情况下，您还必须在速度计算中区分它们。 如果团队不是跨职能的测试人员，就不会真正提高你的速度。 您的速度将是开发人员可以实现的最大速度，但不会超过测试人员可以测试的速度（如果必须测试所有内容）。
与你的 Scrum Master 交谈，否则总会出现速度和估计方面的问题。
现在说说测试人员和冲刺的早期阶段。 我在拥有 5 名开发人员的非跨职能团队中担任测试人员，所以这个答案可能有点个人化。
您可以通过两种方式解决这个问题：a）通过添加单独的测试冲刺来更改工作组织或b）更改测试人员的工作方式。
在 a) 中，您创建单独的测试冲刺。 它可以与开发冲刺并行发生（只是转移了这几天），或者你可以让它每两到三个开发冲刺发生一次。
我听说过这种解决方案，但我从未以这种方式工作过。
在 b) 中，您必须要求测试人员审查他们的测试活动方法。 也许这取决于您使用的实践和工具，或者您遵循的流程，但它们怎么可能在早期毫无作用呢？ 正如我之前提到的，我在非跨职能团队中与 5 名开发人员一起担任测试人员。 如果我要等到开发人员结束他的任务才开始我的工作，我永远不会在给定的冲刺中测试所有功能。 除非您的测试人员仅执行探索性测试，否则他们应该在将功能发布到测试环境之前有一些事情要做。 在测试人员获得功能/代码之前可以完成（或必须完成）一些活动。 以下是我在将功能发布到测试环境之前所做的事情：
- 详细了解要实现的功能的要求
- 设计测试脚本（高级设计）
- 准备测试用例草案
- 检查可能的测试数据（如果正在实施的更改正在操纵系统中的数据，您需要制作该数据的快照，以便稍后将其与给定功能对此数据执行的操作进行比较）
- 将所有内容包装在测试套件中
- 在开发功能时与开发人员沟通 - 这样您可以更好地理解已实现的解决方案（而不是询问他何时已经考虑了其他功能）
- 随着功能的发展，您可以对测试用例进行任何必要的更改
然后，当功能完成时，您：
- 用您之前不知道的任何细节充实测试用例（这很简单，但按钮名称可以更改，或者向导中出现一些附加步骤）
- 执行测试
- 上升问题
。
实际上，我发现自己在第一部分（设计测试，并在适当的工具中准备测试脚本）上花费的时间比实际执行这些测试的时间要多。
如果他们立即尽其所能，而不是等待代码发布到测试环境，这应该有助于弥补这个初始差距，并将最大限度地减少测试人员在冲刺结束之前未完成活动的风险。
当然，测试人员在开始时要做的事情总是较少，而在最后要做的事情却较多，但您可以尝试最小化这种差异。 即使上面的内容仍然让他们在开始时浪费很多时间，你也可以给他们不涉及编码的任务。 一些配置，一些维护，文档更新，其他。
First answer for velocity, than my personal insight about testers in scrum non cross functional team and early days of every sprint.
I see there inconsistency. If team is not cross functional you distinguish testers and developers. In this case you must distinguish them also in velocity calculation. If the team is not cross functional testers don’t really increase your velocity. Your velocity will be max of what developers can implement but no more than what testers can test (if everything must be tested).
Talk to your scrum master, otherwise there will always be problems with velocity and estimation.
Now as for testers and early days of sprint. I work as tester in not cross functional team with 5 devs, so this answer may be bit personal.
You could solve this in two ways: a)change work organization by adding separate test sprint or b) change the way testers work.
In a) you crate separate testing sprint. It can happen in parallel to devs sprint (just shifted those few days) or you can make it happen once every two or three dev sprints.
I have heard about this solutions but I had never worked this way.
In b) you must ask testers to review their approach to testing activities. Maybe it depends on practices and tools you use, or process you follow but how can they have nothing to do in this early days? As I mentioned before I work as tester with 5 developers in not cross functional team. If I would wait with my work until developer ends his task, I would never test all features in given sprint. Unless your testers perform only exploratory testing they should have things to do before feature is released to test environment. There are some activities that can be done (or must be done) before tester gets feature/code into his hands. The following is what I do before features are released to test environment:
- go through requirements for features to be implemented
- design test scripts (high level design)
- prepare draft test cases
- go through possible test data (if change that is being implemented is manipulating data in the system you need to make snapshot of this data, to compare it later with what given feature will do to this data)
- wrap up everything in test suites
- communicate with developer as feature is being developed - this way you can get better understanding of implemented solution (instead of asking when he has his mind already on other feature)
- you can make any necessary changes to test cases as feature evolves
Then when feature is complete you:
- flesh out test cases with any details that not known to you earlier (it is trivial, but button name can change, or some additional step in wizard appears)
- perform tests
- rise issues
.
Actually I find my self to spend more time on first part (designing tests, and preparing test scripts in appropriate tool) than actually performing those tests.
If they to all they can right away instead of waiting for code to be released to test environment it should help with this initial gap and it will minimize risk of testers not finishing their activities before end of sprint.
Of course there will always be less for testers to do in the beginning and more in the end, but you can try to minimize this difference. And even when above still leaves them lots of time to waste at the beginning you can give them no coding involved tasks. Some configuration, some maintenance, documentation update, other.
在我看来，您的系统正在运行，只是没有您想要的那么好。 这是付费项目吗？ 如果是这样，你可以让薪酬成为精英制度。 根据人们完成的工作量来支付报酬。 这将鼓励跨学科工作。 尽管如此，它也可能会鼓励人们从事原本不属于他们的作品，或者进行内部破坏。
显然，你必须留意那些试图玩弄系统的人，但这可能会起作用。 测试人员肯定不想赚到开发人员的一半。
Sounds to me like your system is working, just not as well as you'd like. Is this a paid project? If it is, you could make pay be a meritocracy. Pay people based on how much of the work they get done. This would encourage cross discipline work. Although, it might also encourage people to work on pieces that weren't theirs to begin with, or internal sabotage.
Obviously, you'd have to be on the lookout for people trying to game the system, but it might work. Surely testers wouldn't want to earn half of what devs do.
让测试人员作为被动同伴进行结对编程。 如果他们没有什么可测试的，至少他们可以留意现场的错误。 当他们有东西要测试时，在本周的后半部分，他们会转向功能/“用户故事合规性”级别的测试。 这样，两个小组都富有成效，并且基本上测试人员在代码运行时“梳理”代码。
Make the testers pair-program as passive peers. If they have nothing to test, at least they can watch out for bugs on the field. When they have something to test, in the second part of the week, they move to the functionality/"user story compliance" level of testing. This way, you have both groups productive, and basically the testers "comb" the code as it goes on.
这可能与您的要求略有不同，但事实是：
我真的不喜欢使用速度来衡量下一个冲刺/迭代中要做多少工作。 对我来说，速度更像是一种预测工具。
团队负责人/项目经理/Scrum Master 可以查看最后几次迭代的平均速度，并有一个相当好的趋势线来预测项目的结束。
团队应该作为一个团队通过承诺来构建迭代。 继续挑选故事，直到迭代完成团队承诺完成的大量工作。 作为一个团队，你有责任确保你不会因为选择少数人而懈怠，也不会因为选择太多人而过度承诺。 当团队致力于迭代时，不同的技能水平和专业会自行发挥作用。
在这个模型下，一切都平衡了。 团队有合理的工作量需要完成，项目经理有完成的承诺。
This might be slightly off what you were asking, but here it goes:
I really don't like using velocity as a measure of how much work to do in the next sprint/iteration. To me velocity is more of a tool for projections.
The team lead/project manager/scrum master can look at the average velocity of the last few iterations and have a fairly good trend line to project the end of the project.
The team should be building iterations by commitment as a team. Keep picking stories until the iteration has a good amount of work that the team will commit to complete. It's your responsibility as a team to make sure you aren't slacking by picking to few and not over committing by picking to many. Different skill levels and specialties work themselves out as the team commits to the iteration.
Under this model, everything balances out. The team has a reasonable work load to accomplish and the project manager has a commitment for completion.
FogBugz 使用 EBS（基于证据的调度）根据现有的性能数据和估计创建何时交付给定项目的概率曲线。
我想你可以用这个做同样的事情，只是你需要为测试人员输入：“浏览互联网等待开发人员（1 周）”
FogBugz uses EBS (Evidence Based Scheduling) to create a probability curve of when you will ship a given project based on existing performance data and estimates.
I guess you could do the same thing with this, just you would need to enter for the testers: "Browsing Internet waiting for developers (1 week)"
我们也在这个问题上挣扎。
这就是我们所做的。 当我们将能力和任务相加时，我们将它们一起或单独相加。 这样我们就知道我们没有超过每组的总时间。 （我知道这不是真正的 Scrum，但我们有 QA 人员，他们不会编程，因此，为了最大限度地利用我们的资源，他们最终进行测试，而我们（开发人员）最终进行开发。）
我们所做的第二个想法是，我们真的专注于切片工作。 我们尝试选择首先完成的任务，这些任务可以快速交给质量检查人员。 这样做的技巧是，您必须专注于完成最少的可测试量并将其移交给测试人员。 如果你试图完成一个完整的“功能”，那么你就错过了重点。 当他们等待我们时，他们通常会制定测试计划。
对我们来说，这仍然是一项正在进行的工作，但这就是我们尝试做的事情。
We struggle with this issue too.
Here is what we do. When we add up capacity and tasks we add them up together and separately. That way we know that we have not exceeded total time for each group. (I know that is not truly scrum, but we have QA folks that don't program and so, to maximize our resources, they end up testing and we (the developers) end up deving.)
The second think we do is we really focus on working in slices. We try to pick tasks to get done first that can go to the QA folks fast. The trick to this is that you have to focus on getting the least testable amount done and moved to the testers. If you try to get a whole "feature" done then you are missing the point. While they wait for us they usually put together test plans.
It is still a work in progress for us, but that is how we try to do it.
由于敏捷开发涉及透明度和问责制，听起来测试人员应该分配考虑其速度的任务。 即使这意味着他们有一项上网等待测试的任务（尽管我认为他们最好为开发团队的任务制定测试计划）。 这将显示您组织中的低效率，这并不受欢迎，但这就是敏捷的全部内容。 不好的部分是，您的测试人员可能会因为组织问题而受到惩罚。
我工作的公司有两个独立的（开发和质量保证）团队，有两个不同的迭代周期。 质量保证周期被抵消了一周。 这种不幸导致了任务接受的复杂性，因为直到质量保证迭代结束时产品才真正准备好发布。 这不是一个适当整合的团队，但从听起来也不是你的团队。 不幸的是，质量保证团队从未真正遵循 Scrum 实践（没有真正的计划、站立或回顾），所以我无法真正判断这是否是一个好的解决方案。
Since Agile development is about transparency and accountability it sounds like the testers should have assigned tasks that account for their velocity. Even if that means they have a task for surfing the web waiting for testing (though I would think they would be better served developing test plans for the dev team's tasks). This will show the inefficiencies in your organization which isn't popular but that is what Agile is all about. The bad part of that is that your testers may be penalized for something that is a organizational issue.
The company I worked for had two separate (dev and qa) teams with two different iteration cycles. The qa cycle was offset by a week. That unfortunatey led to complexity when it came to task acceptance, since a product wasn't really ready for release until the end of the qa's iteration. That isn't a properly integrated team but neither is yours from the sound of it. Unfortunately the qa team never really followed scrum practices (No real planning, stand up, or retrospective) so I can't really tell if that is a good solution or not.