The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.
There are three fundamental roles in the Scrum method of agile software development: the Product Owner, the Scrum Master, and the team. The Scrum Master serves as a facilitator for both the Product Owner and the team. The Scrum Master has no authority within the team (thus couldn’t also be the Product Owner!) and may never commit to work on behalf of the team.
In Scrum, the Scrum Master demands a distinct personality type to succeed. The best Scrum Masters are real team players, who feel as much satisfaction from facilitating others’ success as their own. They must also be comfortable surrendering control to the Product Owner and team. For those reasons, traditional project managers don’t always make great Scrum Masters, especially if they’ve previously managed the same team members. But there are exceptions. Perhaps it’s best to let the team and Product Owner decide who should be their Scrum Master.
So what does a Scrum Master do? The Scrum Master remove any impediments that obstruct a team’s pursuit of its sprint goals. If developers are complaining about the high temperature in the team room, the Scrum Master must find a way to cool it down. If outsiders interrupt and distract the team, the Scrum Master must redirect them to the Product Owner.
As the team turns into a self-managing entity, the Scrum Master’s role shifts toward the impediments caused by the outer organization. If the team depends on outsiders, the Scrum Master must help transform the organization to use cross-component, cross-functional feature teams. If “Human Resources” policies (e.g. performance appraisals and job titles) interfere with intrinsic motivation and teamwork, the Scrum Master must educate the business about the harm caused by those policies (incidentally, agile advocates don’t refer to humans as resources).
To understand the full scope of the Scrum Master role, see the Scrum Master checklist.
posted by: scrum methodologyTags: The ScrumMaster Role
Posted by admin under Scrum Basics
There are three roles in the Scrum method of agile software development: the Product Owner, the ScrumMaster, and the team.
In Scrum, the Product Owner is the one person responsible for a project’s success. The Product Owner leads the development effort by conveying his or her vision to the team, outlining work in the Product Backlog, and prioritizing it based on business value. Of course, he or she must also consider the stakeholders and the team. As such, the Product Owner must be available to the team to answer questions and deliver direction.
This combination of authority and availability to the development team makes it hard for the Scrum Product Owner not to micro-manage. Scrum values self-organization and, as a result, the Product Owner must respect the team’s ability to create its own plan of action. This means that a Product Owner is forbidden to give the team more work in the middle of the sprint. Even if requirements change or a rival organization unveils a new product that renders the team’s work all for naught, the Scrum Product Owner is discouraged from altering the sprint until the next sprint planning meeting. However, the Product Owner may cancel a Sprint when necessary. One Product Owner I know cancels Sprints once or twice per year tops.
It is the Product Owner’s responsibility to consider which activities will produce the most business value. This means making tough decisions—that the team might not appreciate—during sprint planning. However, the Product Owner is the one person who must face the music if the project crashes and burns. Therefore, he or she must aggressively determine which features of a product are most important, when they are developed, etc. Just as the development team must produce the negotiated work for the Product Owner, the Product Owner must deliver the product to the customer.
The responsibilities of the Product Owner are also described about halfway through this video module:
Posted by admin under Scrum Basics
In Scrum, the product backlog is the single most important artifact. The product backlog is, in essence, an incredibly detailed analysis document, which outlines every requirement for a system, project, or product. In simpler terms, it could be described as a comprehensive to-do list, expressed in priority order based on the business value each piece of work will generate. Philosophically, the scrum backlog is the engine of the business; it breaks the big-picture story down into manageable increments of work called Product Backlog Items (PBIs).
When the sprint planning meeting occurs, the Scrum team converses with the Product Owner to determine what work they will tackle in the impending iteration. At this time, the Product Owner imports PBIs from the into the sprint backlog.
Now, you may be wondering what a backlog looks like. The answer to that rests on whether a Scrum team uses manual agile or an agile tool to track progress. With manual agile, a team would create a physical manifestation of the backlog, using a dry erase board, Post It notes, or a taskboard. This is ideal for teams that work in closely proximity, whether the same office or room. In this setting, every team member has easy access to the product backlog, the sprint backlog, and the status of its stories; they can simply get up from their desks and walk over to them.
When Scrum teams are not collocated, however, they often require a tool to help them all stay on the same page. There are numerous tools designed to bring geographically distributed teams together using a virtual taskboard. Danube publishes ScrumWorks® Pro, a Scrum management tool that gives users a Web-based task management interface that mimics the look and feel of a physical taskboard. The tool also offers more detailed views of the product and sprint backlogs, organized in adjacent panes and easily modified with drag-and-drop prioritization.
Although it is the team’s responsibility for completing the work, the Product Owner is the only one who can prioritize work in the scrum backlog or, after negotiating with the team, add work to the sprint backlog.Tags: backlog items, scrum backlog, scrum backlog items, Scrum Methodology, scrum PBIs
Posted by admin under Scrum Basics
While backlog refinement (also called grooming) was not originally a formal meeting in the Scrum framework, Ken Schwaber, who founded Scrum, advises teams to dedicate five percent of every sprint to this activity. As with Scrum’s other meetings, the grooming should take place at the same time and place and for the same duration each sprint.
Everyone attends the backlog refinement meeting: the team, the Product Owner, and the ScrumMaster. During the meeting, everyone helps prepare the Product Backlog for the sprint planning meeting. This usually includes adding new stories and epics, extracting stories from existing epics, and estimating effort for existing stories. Why is this helpful? Because a groomed backlog will help streamline sprint planning meetings; otherwise, they can stretch on for hours. When product backlog items contain clearly defined acceptance criteria and are estimated by the team members, the planning process does not have to be tense or overly long. By dedicating a time to backlog maintenance, the team ensures that this preliminary planning occurs prior to the sprint planning meeting.backlog grooming, scrum backlog, scrum backlog grooming, Scrum Methodology
Scrum Training Series
- Scrum based funding model – 20 percent May 9, 2013
- The Next Big Idea March 5, 2013
- On Being Available February 17, 2013
- Should Scrum Always Require the Product Owner to Attend the Sprint Retrospective Meeting? February 5, 2013
- Happiness Metrics January 23, 2013