“An adequate ScrumMaster can handle two or three teams at a time. If you’re content to limit your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation at your organization, and probably nothing catastrophic will happen.
in this blog post, John Piekos explains how the ScrumMaster and Product Owner roles in Scrum are much more demanding than the Project and Product Manager roles of traditional project approaches. With frequent “potentially shippable product increments”, he believes that full-time effort is required from all members in order to be successful.
The five stories presented in this article, mostly based on real life, might help you see how Agile can become mechanical and what you should do about this. You will also learn some solutions that could help to solve all five symptoms. We need to allow people to act like people and not try to force them into a machine model that we have created for them.
In the past, the Scrum Guide consistently used the word “priority” for the Product Backlog or noted that the Product Backlog was “prioritized.” While the Product Backlog must be ordered, prioritization is only one technique and rarely a good one to achieve this objective. The new Scrum Guide instead uses the term ordered for the Product Backlog.
Implementing Scrum on a custom (or bespoke) software development project can be difficult and many organizations new to the agile methodology struggle to adopt it. Typical issues/obstacles that arise include lack of business ownership and the inability to make decisions, limited business buy-in into the concept of Agile or team communication and individual skills. When introducing Agile, organizations often attempt to tackle all of these issues head on and get overwhelmed with the new methodology, then choosing to revert back to what they are familiar with. Why not moving gradually to Scrum, enabling an organization to deal with issues one at a time and gain the benefits associated with solving each issue gradually?
This article provides an overview on the derivation and application of user stories, which are the primary concept that represent the user requirements in agile software development approaches like Scrum. Its goal is to describe the user story in detail, because it contains the key agile practices that help align solutions directly to the user’s specific needs, assuring quality at the same time.
In this blog post, Ken Pugh compares the usage of Kanban board and Scrum tracking boards to track progress of agile projects. He concludes that Scrum-style boards and Kanban-style boards can provide the same information, but in different ways.
Scrum Expert Copyright © 2009-2024 Martinig & Associates