scrum

Having used "days" as the unit for estimation of tasks in Scrum I find it hard to change to using Story Points. I believe story points should be used as they are more comparable to each other - being less dependent on the qualifications of whoever addresses the task etc. However, it isn't easy to make a team start using Story Points when they're used to estimating in days. So, how to make a team change to Story Points? What should motivate the team members to do so, and how should we apply the switch? If you want to change to using story points instead of duration, you just got to start

Let's say that a developer is interested in learning Scrum, but nobody else on the team is interested. I realize that Scrum is made for teams, and the process would have to be modified to fit a single person. Is there any benefit to be gained by the developer trying Scrum, even if the team doesn't? If so, how would the process be modified to suit the situation? I think there's benefit to be gained by any method that helps you develop goals, tasks, keep on top of work and deliver something often. Your individual work-products would gain the same advantages that teams gain with scrum: You'd get

What software do you use to manage Scrum software development ? We've tried Tackle and VersionOne (both free) so far and they are good except for the fact that it's difficult to track work in progress. For example, if I have a task that I estimate will take me 8 hours to complete, I've done 4 hours of work with 4 hours remaining, the task is always reported as 8 hours remaining until it is marked complete, at which time it falls to zero. I'd like to use a tool that will allow me to take an accurate work at the teams WIP at the end of each week and see how much impact that work has had towards

I work in an office which has been doing Agile for a while now. We use Scrum for project management and mix in the engineering practices of XP. It works well and we are constantly learning lessons and refining our process. I would like to tell you about our usual practices for testing and get feedback on how this could be improved: TDD: First Line of Defense We are quite religious about unit testing and I would say our developers are also experienced enough to write comprehensive tests and always isolate the SUT with mocks. Integration Tests For our use, integration tests are basically the

I'm curious as to what other people use for physical Kanban/Scrum boards in their companies. I appreciate that because of sensitive business information you may not be able to provide a photo of the board. I"m looking at to find out what does your board looks like , and how you organize user stories and tasks as they move through a typical sprint/iteration? Typically I've worked in a places that organize the board as follows with each User Story | Todo | In Progress | Ready for QA | Done | UC-001 | Domain Object, Service | DAO(Bob) | | | UC-002 | Payment UI Screen | | Payment Srv (Don)| | UC

I'm fairly well read in the benefits and processes of Scrum. I get the ideas on the backlog, burndown charts, iterations, using user stories, and other various concepts of the Scrum "framework". With that said... I work for a web development firm that manages multiple projects at one time, with six team members that make up the "production team". How does Scrum work with having multiple projects? Do you still just schedule an iteration for a single project in a certain amount of time and the entire team works on it, and then you move on to the next project with a new iteration when that

I have been studying and reading about Scrum in the last few days and reading about Sprint Planning and tasks. One problem that popped into my mind is how to deal with bugs in Scrum. Henrik Kniberg lists some ways of dealing with this issue in his very nice book Scrum and XP from the Trenches : Product owner prints out the most high priority Jira items, brings them to the sprint planning meeting, and puts them up on the wall together with the other stories (thereby implicitly specifying the priority of these items compared to the other stories). Product owner creates stories that refer to Jira

What is the difference between Scrum and Agile Development? Are Sprint and Iterations the same? Sindico Scrum is just one of the many iterative and incremental agile software development methods. You can find here a very detailed description of the process. In the SCRUM methodology, a Sprint is the basic unit of development. Each Sprint starts with a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made. A Sprint ends with a review or retrospective meeting where the progress is reviewed and lessons for the next sprint are

【上次回答了 软件开发者面试百问 中测试部分 ，这次，由于时间关系，简单回答一下软件项目管理部分的问题。这些问题的答案，一般没有正确与否，各个人回答不同，这里仅供大家参考。】 1. 范围、时间、成本，这三项中哪些是可以由客户控制的？ 范围、时间、成本，是项目管理中常说的三角关系。任何一方改变都可能牵扯到其他两方的变动。项目管理的本质，就是在保证质量的前提下，寻求这三者之间的最佳平衡。因为客户是需求方和投资方，客户有权对这三者进行控制，当然客户主要控制范围，即提出他们的需求——项目要实现的功能特性，其次，客户也非常关心能交付的时间和所付出的成本。在满足客户的需求情况下，可以在时间、成本上和客户进行交流、谈判。从项目管理的角度看，最好固定其中一项，其他两项可以根据实际状况来调节保证项目质量。 2. 谁该对项目中所要付出的一切做出估算？谁有权设置最后期限？ 项目成功是团队协作的结果。在对项目进行估算的时候，需要由参与项目各个环节的人进行符合实际的估算，最后汇总起来进行综合分析计算，获得项目总的估算结果。 项目的最后期限设置除了客户定死最后交付时间，其他的情况都是根据项目的进度估算结果而进行符合实际的计划得出的。 3. 减少交付的次数，或是减少每个每个交付中的工作量，你喜欢哪种做法？ 根据项目的类型和项目进行中的实际情况来决定，如果项目是规模比较大，时间长的

来自：http://www.cnblogs.com/raol/archive/2013/05/08/scrum_master_2.html 第二天：早上，我们会讲到Product Owner, Product backlog和渐进式的发布计划，下午，我们会具体探究Scrum Master的角色和团队的角色，并且澄清许多已有的误解。接下来的话题是Scrum的在组织环境下的执行实施。课程的最后，我们会谈到在多个团队的环境 中扩展Scrum的要点，并且分享培训师本人在这个领域的经验。 ------------------------------------------------------------------------------------------------------------------------------------------------------------------ 下面是我的笔记： ------------------------------------------------------------------------------------------------------------------------------------------------------------------ 1. 回顾了下昨天那三个你觉得比较重要？ 2.