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.


The Scrum Master Role

Posted by admin under Scrum Basics, transformation

ScrumMaster Checklist

The Example Scrum Master’s Checklist

Scrum has only three roles: 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. Likewise, the Scrum Master also is not a co-ordinator, because (by definition) self-organizing teams should co-ordinate directly with other teams, departments, and other external entities.

The best Scrum Masters are the types of people 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. Traditional project managers don’t always make great Scrum Masters, especially if they’ve previously managed the same team members. One problem I hear about from recovering project managers is that the teams still look to them for direct instructions rather than stepping up to team self organization. “Self organize, dammit!” But there are exceptions; some amazing Scrum Masters were once project managers. Perhaps it’s best to let the team and Product Owner decide who should be their Scrum Master.

What does a Scrum Master do? The Scrum Master removes any impediments that obstruct a team’s pursuit of its sprint goals. If developers don’t have a good sense of what each other are doing, the Scrum Master helps them set up a physical taskboard and shows the team how to use it. If developers aren’t colocated, the Scrum Master ensures that they have team room. If outsiders interrupt the team, the Scrum Master redirects them to the Product Owner. If the team has not learned how to develop a potentially shippable product increment every Sprint, the Scrum Master teaches them Test Driven Development (TDD), or finds people who can teach them. If the existing code is so bad that it slows down new development, the Scrum Master helps the team learn how to pay off technical debt incrementally.

As the team grows into a self-managing entity, the Scrum Master’s role shifts toward the organizational impediments, issues caused by the outer organization. If the company still has a “business side” and an “IT side”, the Scrum Master works to make each team cross-functional. If the team depends on outsiders, the Scrum Master must help transform the organization to use cross-component 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”).

Scrum Masters are full-time transformation agents, but they do not push for change. What do people do when you push them? They push back. Instead, effective Scrum Masters promote transformation through illumination and invitation. Conversations with executives don’t work without a background of relatedness. In established organizations, improvements come in fits and starts. Sometimes it seems like nothing is changing, then the organization has a breakthrough right when we were about to give up. This can be emotionally taxing, so I advise Scrum Masters to connect with a community of Agilists. Product development is mostly about knowledge creation and collaboration, but most large organizations would require fundamental changes before they could be called learning organizations. Skilled Scrum Masters read books about facilitation, persuasion, mindfulness, and what Marshall Rosenberg called “Nonviolent Communication.”

To understand the full scope of the Scrum Master role, see the Scrum Master checklist, which is referenced by several bestselling Agile books. The Scrum Master Checklist examines four questions effective Scrum Masters consider each day: How is my Team doing? How is my Product Owner doing? How are our technical practices? How is the larger organization doing?

In Large Scale Scrum, the Scrum Master role shifts over time from focus on the team to focus on the larger organization.

About The Author

This article was rewritten by Michael James, an Agile coach and Certified Scrum Trainer based in Seattle (but often found in other cities). Follow MJ on Twitter or LinkedIn.


The Scrum Training Series uses the voice of a real life Scrum Master to re-enact the kinds of scenarios Scrum Masters encounter, such as this Sprint Retrospective Meeting scenario.

Scrum Master facilitates the Sprint Retrospective Meeting



Scrum Product Owner

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 ultimately responsible for the return on investment (ROI) of the product development effort. The Product Owner influences the development effort by conveying his vision to the team(s) and prioritizing the Product Backlog. The Product Owner must have the authority to make real business decisions, vision about what the product could be, and availability to the team(s). In bad implementations of Scrum, one of these elements is usually missing. For example, if I don’t have the authority to cancel product development entirely (an important ROI decision), it’s misleading to call me “Product Owner.”

This combination of authority and availability to the development team makes it hard for the Scrum Product Owner not to micro-manage. Since Scrum is team self-organization, the Product Owner must respect the team’s ability to create its own plan of action. A Product Owner doesn’t demand additional work in the middle of the sprint. The Scrum Product Owner is discouraged from adding work to 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 about what not to do.

In Large Scale Scrum, one Product Owner prioritizes a single Product Backlog for multiple teams. Multiple backlogs for one product — and multiple Product Owners — cause localized optimizations (detracting from a whole product focus), longer work-in-progress queues, thus are harmful to agility. Large Scale Scrum encourages teams to become truly cross functional and take greater responsibility for their own requirements clarifications. Cross functional doesn’t mean only dev + test, it also includes learning the requirements domain.

The responsibilities of the Product Owner are also described about halfway through this video module:
Introduction To Scrum video

Tags: , , ,


The Scrum Backlog

Posted by admin under Scrum Basics

Scrum has two types of backlogs, the Product Backlog, and the Sprint Backlog.

The Product Backlog is a prioritized list of customer-centric features. It breaks the big-picture vision down into manageable increments of work called Product Backlog Items (PBIs). These are typically expressed in user story form. Product Backlog Items are not tasks, they represent the what rather than the how. If Product Backlog Items are estimated, they’re estimated in relative units such as story points. Items toward the top of the Product Backlog should be small enough that a team could accomplish several of them (including proper testing, integration, etc.) in one two-week Sprint.

The Product Owner and Team collaborate to refine the Product Backlog continuously (e.g. about an hour per week) in the Backlog Refinement Meeting.

In Large Scale Scrum, multiple teams pull their work from a single Product Backlog. Multiple teams collaborate with the Product Owner to refine the single Product Backlog.

The Sprint Backlog is created during the Sprint Planning Meeting. The team pulls the amount of work they want to do from the Product Backlog into the Sprint Backlog, and further decomposes the PBIs into Sprint Tasks. The team decides the how, and expresses this in the tasks. The best way to represent the Sprint Backlog is a physical taskboard, using PostIt Notes or index cards. During the Sprint, typically at the Daily Scrum Meeting, team members move the tasks around to reflect how they’re doing on them. One purpose of the Sprint Backlog is to limit work in progress (WIP). Humans become ineffective when they worry about too many things at the same time.

Tags: , , , ,


Scrum Backlog Grooming

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.

Watch an example backlog grooming meeting.

Tags: , , ,