Team should decide whether a tool is to be used; but I think suggestion most commonly comes from the Scrum Master as (s)he is most likely to have experience using tools. Any team member can suggest tools of course.
Anyway, my feeling is that given Scrum philosophy, the whole team needs to agree on this in my opinion. Usually things start with "let's try this, see if it works", and is refined along the way, just like anything else in Scrum. It should not be top-down enforcement, same way as using Scrum methodology should be team decision, not handed down from top.
Great question. There is a lot of value to embracing the self organization of agile and allow the teams to choose their tools. However, there are usually constraints imposed by the business. For instance, the business may not be able to support/want each scrum team rolling its own scm solution. The more established the business, the more constraints and push back. Even established businesses can change. Don't be afraid to question a constraint if the team can justify the change.
Agile planning tools will follow these same rules. The business may have a full software life cycle management solution in place. This solution may or may not have an agile module. However the business may have reasons (regulated industries for example) to require that design inputs / outputs are documented in the life cycle management software solution they have. The business usually needs to balance keeping the teams happy / productive with staying in business.
I don't think there will be a black or white solution (unless you are one of the first devs at a start up). Agile teams will need to embrace the open communication. If the tools are impediments the business needs to know.
I'm going to make simple answer, because I actually think this is a simple question.
The WHOLE team is responsible of that.
Let me explain a little bit. We first have to accept that every context is different, so this is not a biblical answer.
Let's say you start your project. I always love starting my projects/products with nothing. NOTHING. Sometimes, just a task board, with todo, in process, done.
That's it. And I fill the todo column.
And that's all my point: I build my agile process incrementally and iteratively. Why should I have to create a Burndown Chart? Because literacy tells me so?
Hell no, because, maybe, eventually, at some point, I might need to have some visibility for my planning.
Same with everything. And never forget, Agile tools serve as a support for the process.
So, you're a PO, and you're tired of the simple todo list, and fell the need to do a Backlog? 2 Solutions: -- you're already in a highly mature team, you just have to tell everybody during stand up meeting that you're taking the lead on it. Eventually it'll need a retrospective to accept that. -- you're migrating from a V, W or whatever product management model. Then, wait the retrospective and ask everybody and explain your pain. Give solution (here the backlog), and ask for a shot.
So, you're a scrum master, and you find a "systemic bug" in your process, let's take the classic one: Too many bugs. Then take the lead to promote TDD, or systematic testing.
So, you're tech lead and feel... Well, you understood me.
My point is: never over tool your process at the beginning. Build the process slowly, add tools slowly, when you need them. And by doing so, don't worry, people will take reponsability to create the tool and add it to the process, to lobby it to the rest of the team.
What is your experience from real-life, who should be responsible for a choice of agile planning tools to be used by the agile/scrum team?
Well my experience from real life is that, certain "Agile Planning Tools" tools were handed to the Scrum Teams before they even started their Sprints, fortunately the Teams liked it, but we were free to inspect and adapt to using something else if it did not work out for us.
I think it should be in the Teams power to use, accept or reject a tool in a completely transparent way. They could very well take suggestions from the Scrum Master or an Agile Coach because (s)he may have more knowledge in the Agile Tools area. Secondly, the Team should be courageous enough to have a collective discussion and decide on using a tool based on the Agile Coach's suggestions, and see how it works for them, and adapt and adjust from using it if it does not work for them (productivity-wise)
The bigger question which you did not ask is, how do you manage the differing tool set chaos when the company scales into having multiple Scrum Teams who use their own Agile Planning tools?. Well, I think realistically, in a scaling agile software company, a little bit of uniformity in tool usage across Scrum Teams can be beneficial and productive but that may be directed by the self organised enterprise project Team instead of each Team having their own tools. Off course there can be exceptions, where certain teams are working on completely different features and they need a totally different tool set, but the benefit of using common Agile tools will help scaling projects view their Teams progress without much of change in gear.
The above can be done by having a Technical, Infrastructure and Process Tools Story which not many companies use or create. This EPIC story can be the starting point for discussion of what Agile tools and other tools can be used, to have a little uniformity within the project. While deriving the EPIC story the whole project team could be involved around project kick off, if it is too big then 1 - 2 members can represent each of the Teams. The story could be broken down exactly like business user stories, and modified accordingly and calibrated, estimated and prioritized through out the project from an infrastructure and tools stand point. Let me know if you want me to go in more detail about this.
Ideally the scrum master, but they may inherit some legacy which needs some evolution.
If the organisation is new to Scrum, then an experienced Scrum Master should be able to advise the best tools for the maturity of the team.
Typically, if a team already has some tools, a scrum master can adapt what is already there, regardless of the organisational choice. Some of the best boards are on Excel Spreadsheets and work just as well as a purpose built system. Every technology creates 'constraint'. So, it is up to the scrum master to support the business in ensuring the tools are fit for purpose and delivering the value the team needs.
Typical mistake I experienced as a coach was decision made by managers or even senior management according some study done by 'specialist' or even external consultant. Those people are many times not aware about what, how and who will yse the tool. In this case I see dissapointed people once they should use chosen tool.
You have to consider who is going to use the tool for most of the day. Team members are better target community. Tool must support ScrumMaster role due to daily work she needs to done. Include experienced product owners into selection of the tool as tools have different support for planning that is necessary to be usable.
Consider your organization (complexity of products, projects, number of locations)
The responsibility (and authority) of choosing a planning tool should be with the team. Often the surrounding organization will have a stake in terms of licensing costs and consistency across teams. Depending on how autonomous your teams are it should be OK for them to chose their own tool, though.
Within the team, the product owner usually has the highest stake in the decision, since he will be the one who is going to use it the most for continuous refinement and prioritizing. The rest of the team often only interacts with the planning tool during refinement and planning sessions once or twice each sprint. So he is usually the one driving the decision-making, but should definitely involve the team.
If the chosen tool also includes a board that the team uses daily to track their work, they will want to have more of a say in the choice.
发布评论
评论（7）
团队应决定是否使用某种工具；但我认为建议最常来自 Scrum Master，因为他（她）最有可能拥有使用工具的经验。当然，任何团队成员都可以推荐工具。
无论如何，我的感觉是，鉴于 Scrum 哲学，整个团队需要就我的观点达成一致。通常事情都是从“让我们试试这个，看看它是否有效”开始，然后一路完善，就像 Scrum 中的其他任何事情一样。它不应该是自上而下的执行，就像使用 Scrum 方法一样，应该是团队决策，而不是自上而下的。
Team should decide whether a tool is to be used; but I think suggestion most commonly comes from the Scrum Master as (s)he is most likely to have experience using tools. Any team member can suggest tools of course.
Anyway, my feeling is that given Scrum philosophy, the whole team needs to agree on this in my opinion. Usually things start with "let's try this, see if it works", and is refined along the way, just like anything else in Scrum. It should not be top-down enforcement, same way as using Scrum methodology should be team decision, not handed down from top.
很好的问题。拥抱敏捷的自组织并允许团队选择他们的工具有很多价值。然而，企业通常会施加一些限制。例如，企业可能无法支持/希望每个 scrum 团队推出自己的 scm 解决方案。企业越成熟，限制和阻力就越多。即使是成熟的企业也可能会发生变化。如果团队能够证明更改的合理性，请不要害怕质疑约束。
敏捷规划工具将遵循这些相同的规则。企业可能拥有完整的软件生命周期管理解决方案。该解决方案可能有也可能没有敏捷模块。然而，企业可能有理由（例如受监管的行业）要求将设计输入/输出记录在他们拥有的生命周期管理软件解决方案中。企业通常需要在保持团队快乐/高效与维持业务之间取得平衡。
我认为不会有非黑即白的解决方案（除非您是初创公司的第一批开发人员之一）。敏捷团队需要拥抱开放式沟通。企业需要知道这些工具是否是障碍。
Great question. There is a lot of value to embracing the self organization of agile and allow the teams to choose their tools. However, there are usually constraints imposed by the business. For instance, the business may not be able to support/want each scrum team rolling its own scm solution. The more established the business, the more constraints and push back. Even established businesses can change. Don't be afraid to question a constraint if the team can justify the change.
Agile planning tools will follow these same rules. The business may have a full software life cycle management solution in place. This solution may or may not have an agile module. However the business may have reasons (regulated industries for example) to require that design inputs / outputs are documented in the life cycle management software solution they have. The business usually needs to balance keeping the teams happy / productive with staying in business.
I don't think there will be a black or white solution (unless you are one of the first devs at a start up). Agile teams will need to embrace the open communication. If the tools are impediments the business needs to know.
我会做一个简单的回答，因为我实际上认为这是一个简单的问题。
整个团队都对此负责。
让我解释一下。
我们首先必须接受每个环境都是不同的，所以这不是圣经的答案。
假设您开始了您的项目。我总是喜欢从一无所有开始我的项目/产品。
没有什么。有时，只是一个任务板，上面有待办事项、正在进行中、已完成。
就是这样。我填写待办事项栏。
这就是我的全部观点：我以增量和迭代的方式构建我的敏捷流程。
为什么我必须创建燃尽图？因为识字告诉我所以吗？
天哪，不，因为，也许，最终，在某个时候，我可能需要对我的计划有一定的了解。
一切都一样。永远不要忘记，敏捷工具是流程的支持。
那么，您是采购员，您厌倦了简单的待办事项列表，并且不需要做待办事项列表？
2 解决方案：
——你已经在一个高度成熟的团队中，你只需要在站立会议上告诉每个人你正在带头。最终需要进行回顾才能接受这一点。
-- 您正在从 V、W 或任何产品管理模型迁移。然后，等待回顾并询问每个人并解释你的痛苦。给出解决方案（这里是待办事项），并请求尝试。
因此，您是一名 Scrum Master，并且您在流程中发现了“系统性错误”，让我们以经典的错误为例：错误太多。然后带头推广TDD，或者说系统测试。
所以，你是技术主管，并且感觉……嗯，你理解我的意思。
我的观点是：永远不要在一开始就过度工具化你的流程。慢慢构建流程，在需要时慢慢添加工具。通过这样做，不用担心，人们将承担起创建工具并将其添加到流程中的责任，并将其游说给团队的其他成员。
希望这有帮助。
I'm going to make simple answer, because I actually think this is a simple question.
The WHOLE team is responsible of that.
Let me explain a little bit.
We first have to accept that every context is different, so this is not a biblical answer.
Let's say you start your project. I always love starting my projects/products with nothing.
NOTHING. Sometimes, just a task board, with todo, in process, done.
That's it. And I fill the todo column.
And that's all my point: I build my agile process incrementally and iteratively.
Why should I have to create a Burndown Chart? Because literacy tells me so?
Hell no, because, maybe, eventually, at some point, I might need to have some visibility for my planning.
Same with everything. And never forget, Agile tools serve as a support for the process.
So, you're a PO, and you're tired of the simple todo list, and fell the need to do a Backlog?
2 Solutions:
-- you're already in a highly mature team, you just have to tell everybody during stand up meeting that you're taking the lead on it. Eventually it'll need a retrospective to accept that.
-- you're migrating from a V, W or whatever product management model. Then, wait the retrospective and ask everybody and explain your pain. Give solution (here the backlog), and ask for a shot.
So, you're a scrum master, and you find a "systemic bug" in your process, let's take the classic one: Too many bugs. Then take the lead to promote TDD, or systematic testing.
So, you're tech lead and feel... Well, you understood me.
My point is: never over tool your process at the beginning. Build the process slowly, add tools slowly, when you need them. And by doing so, don't worry, people will take reponsability to create the tool and add it to the process, to lobby it to the rest of the team.
Hope this helps.
我在现实生活中的经验是，某些“敏捷规划工具”工具在 Scrum 团队开始 Sprint 之前就已经交给了他们，幸运的是团队喜欢它，但如果确实如此，我们可以自由地检查和适应使用其他工具不适合我们。
我认为团队应该有权以完全透明的方式使用、接受或拒绝工具。他们很可能会听取 Scrum Master 或敏捷教练的建议，因为他可能在敏捷工具领域拥有更多知识。其次，团队应该有足够的勇气进行集体讨论，根据敏捷教练的建议决定使用某个工具，看看它对他们是否有效，如果它不适合他们，就使用它进行调整和调整（生产力） -明智）
您没有问的更大问题是，当公司规模扩大到拥有多个使用自己的敏捷规划工具的 Scrum 团队时，您如何管理不同工具集的混乱？
好吧，我实际上认为，在规模化敏捷软件公司中，Scrum 团队之间工具使用的一点统一性可能是有益且富有成效的，但这可能是由自组织的企业项目团队指导，而不是每个团队拥有自己的工具。当然也有例外，某些团队正在开发完全不同的功能，并且需要完全不同的工具集，但使用通用敏捷工具的好处将有助于扩展项目查看其团队的进度，而无需进行太多的装备更改。
上述内容可以通过拥有一个没有多少公司使用或创建的技术、基础设施和流程工具故事来完成。这个史诗般的故事可以作为讨论可以使用哪些敏捷工具和其他工具的起点，以便在项目中具有一点统一性。在推导 EPIC 故事时，整个项目团队可以在项目启动时参与其中，如果规模太大，则每个团队可以由 1 - 2 名成员代表。该故事可以像业务用户故事一样进行分解，并从基础设施和工具的角度在整个项目中进行相应的修改和校准、估计和优先级排序。如果您希望我更详细地介绍这一点，请告诉我。
Well my experience from real life is that, certain "Agile Planning Tools" tools were handed to the Scrum Teams before they even started their Sprints, fortunately the Teams liked it, but we were free to inspect and adapt to using something else if it did not work out for us.
I think it should be in the Teams power to use, accept or reject a tool in a completely transparent way. They could very well take suggestions from the Scrum Master or an Agile Coach because (s)he may have more knowledge in the Agile Tools area. Secondly, the Team should be courageous enough to have a collective discussion and decide on using a tool based on the Agile Coach's suggestions, and see how it works for them, and adapt and adjust from using it if it does not work for them (productivity-wise)
The bigger question which you did not ask is, how do you manage the differing tool set chaos when the company scales into having multiple Scrum Teams who use their own Agile Planning tools?.
Well, I think realistically, in a scaling agile software company, a little bit of uniformity in tool usage across Scrum Teams can be beneficial and productive but that may be directed by the self organised enterprise project Team instead of each Team having their own tools. Off course there can be exceptions, where certain teams are working on completely different features and they need a totally different tool set, but the benefit of using common Agile tools will help scaling projects view their Teams progress without much of change in gear.
The above can be done by having a Technical, Infrastructure and Process Tools Story which not many companies use or create. This EPIC story can be the starting point for discussion of what Agile tools and other tools can be used, to have a little uniformity within the project. While deriving the EPIC story the whole project team could be involved around project kick off, if it is too big then 1 - 2 members can represent each of the Teams. The story could be broken down exactly like business user stories, and modified accordingly and calibrated, estimated and prioritized through out the project from an infrastructure and tools stand point. Let me know if you want me to go in more detail about this.
理想情况下是 Scrum Master，但他们可能会继承一些需要进化的遗产。
如果组织是 Scrum 新手，那么经验丰富的 Scrum Master 应该能够为团队的成熟度提供最佳工具建议。
通常，如果团队已经拥有一些工具，那么无论组织选择如何，Scrum Master 都可以调整已有的工具。一些最好的看板都在 Excel 电子表格上，并且与专门构建的系统一样好用。每项技术都会产生“约束”。因此，Scrum Master 需要支持业务，确保工具适合目的并提供团队所需的价值。
Ideally the scrum master, but they may inherit some legacy which needs some evolution.
If the organisation is new to Scrum, then an experienced Scrum Master should be able to advise the best tools for the maturity of the team.
Typically, if a team already has some tools, a scrum master can adapt what is already there, regardless of the organisational choice. Some of the best boards are on Excel Spreadsheets and work just as well as a purpose built system. Every technology creates 'constraint'. So, it is up to the scrum master to support the business in ensuring the tools are fit for purpose and delivering the value the team needs.
我作为教练所经历的典型错误是经理甚至高级管理层根据“专家”甚至外部顾问所做的一些研究做出的决定。这些人很多时候并不知道该工具将使用什么、如何使用以及由谁使用。在这种情况下，我看到人们一旦应该使用所选工具就会感到失望。
您必须考虑谁将在一天的大部分时间里使用该工具。团队成员是更好的目标社区。由于 ScrumMaster 需要完成日常工作，工具必须支持她的角色。让经验丰富的产品所有者参与工具的选择，因为工具对可用的规划有不同的支持。
考虑您的组织（产品、项目的复杂性、地点数量）
Typical mistake I experienced as a coach was decision made by managers or even senior management according some study done by 'specialist' or even external consultant. Those people are many times not aware about what, how and who will yse the tool. In this case I see dissapointed people once they should use chosen tool.
You have to consider who is going to use the tool for most of the day. Team members are better target community. Tool must support ScrumMaster role due to daily work she needs to done. Include experienced product owners into selection of the tool as tools have different support for planning that is necessary to be usable.
Consider your organization (complexity of products, projects, number of locations)
选择规划工具的责任（和权力）应该由团队承担。通常，周围的组织会在许可成本和团队之间的一致性方面有利害关系。不过，根据您的团队的自主程度，他们应该可以选择自己的工具。
在团队中，产品负责人通常在决策中拥有最高的利益，因为他将是最常使用决策进行持续改进和确定优先级的人。团队的其他成员通常只在每个冲刺的细化和规划会议期间与规划工具交互一两次。因此，他通常是推动决策的人，但绝对应该让团队参与进来。
如果所选工具还包括团队每天用来跟踪工作的看板，他们将希望在选择中拥有更多发言权。
The responsibility (and authority) of choosing a planning tool should be with the team. Often the surrounding organization will have a stake in terms of licensing costs and consistency across teams. Depending on how autonomous your teams are it should be OK for them to chose their own tool, though.
Within the team, the product owner usually has the highest stake in the decision, since he will be the one who is going to use it the most for continuous refinement and prioritizing. The rest of the team often only interacts with the planning tool during refinement and planning sessions once or twice each sprint. So he is usually the one driving the decision-making, but should definitely involve the team.
If the chosen tool also includes a board that the team uses daily to track their work, they will want to have more of a say in the choice.