eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The best way for organizations to get started with Scrum is for them to first develop a strong understanding of Scrum’s language and mechanics. Once these basic aspects of the Scrum framework are understood, the hard work of enacting change and internalizing the framework’s values can begin.
What follows is an introduction to Scrum’s roles, artifacts and meetings, as well as advice for how organizations can successfully acclimate to a new approach to project management. After all, the language and mechanics of Scrum are quite simple, but its implementation is considerably more difficult.
The Scrum roles
In Scrum, products are built incrementally over a series of consecutive development iterations called “Sprints.” Scrum defines three roles that are responsible for managing both the process and the product development effort: Product Owner, ScrumMaster and the Scrum Team.
When transitioning from traditional project management methods, it is important that individuals are chosen for the Scrum roles based on inclination, temperament, and skills-not their position within the corporate hierarchy. Forcing someone into a role for which they are poorly suited or lack personal interest is a recipe for failure. Let’s look at each of these roles:
1. The Product Owner
According to Scrum co-founder Ken Schwaber, the Product Owner is “the person who is officially responsible for the project.” Responsibilities include:
– Defining product features
– Understanding business/stakeholder needs
– Prioritizing feature delivery based on stakeholder needs
– Arbitrating requirements issues
– Defining development priorities at the beginning of each Sprint
– Negotiating acceptance criteria for features with the Scrum Team
– Accepting or rejecting results of each cycle
– Planning releases
The Product Owner decides which features will be built into a product and the relative priority of each item. Moreover, the Product Owner must be highly attuned to the value generated by these features to ensure high-value features are delivered as early as possible to encourage feedback that leads to maximum ROI.
The ScrumMaster
2. The ScrumMaster
The ScrumMaster is responsible for the success of the process and the productivity and health of the Scrum Team. According to Schwaber, the “ScrumMaster is responsible for the success of Scrum.” Further, the “ScrumMaster is responsible for ensuring that Scrum values, practices and rules are enacted and enforced. The ScrumMaster is the driving force behind all of the Scrum practices.” Responsibilities include:
– Keeping the process moving
– “Enforcing” the Scrum framework
– Facilitating and ensuring full-team involvement in all Scrum’s meetings
– Keeping everything visible
– Communicating and sharing information to the larger organization
– Shielding the team from external interference
– Helping surface and remove obstacles impeding the Scrum Team from achieving its Sprint goals
– Advocating improved practices
– Tracking progress and posting it visibly
Good ScrumMasters spend considerable time helping the rest of the organization understand Scrum, including the Product Owner.
It is important to understand that the ScrumMaster has no authority and is not a manager of people or projects. In addition, the ScrumMaster doesn’t assign tasks to team members or monitor individual team member performance. Rather, the ScrumMaster must understand he or she is not “in charge” of anything.
The role is one of “servant leadership” which relies on personal persuasiveness rather than organizational authority. In short, they serve the team by reminding them about the rules of the Scrum process; ultimately, it is up to the Scrum Team to observe those rules.
The Scrum Team
3. The Scrum Team
The Scrum Team is comprised of about seven (plus or minus two) team members. Scrum advocates cross-functionality to allow a single team to accomplish development goals.
Responsibilities include:
– Estimating effort to complete Product Backlog Items
– Committing to what it thinks it can accomplish each Sprint
– Managing development of product functionality
– Building Business Value
– Defining its work (who does what and how)
– Building and maintaining its schedule for the Sprint
– Negotiating scope and acceptance criteria for Sprint goals
– Anything required to turn a stakeholder’s request into functional product
One challenge for organizations that adopt Scrum is allowing teams to self-manage and self-organize. Often, existing organizational structures directly conflict with giving the team the autonomy required to accomplish its goals. Such organizations must actively shift from a parent/child relationship to a peer/peer relationship between management and “staff.” This is where an effective and experienced ScrumMaster can play a crucial role in facilitating a smooth transition.
Scrum Ceremonies and Artifacts
Scrum ceremonies and artifacts
The Scrum process itself prescribes only four meetings: Sprint Planning, the Daily Scrum, Sprint Review, and Sprint Retrospective. In addition, Scrum advocates face-to-face collaboration among team members and with various stakeholders. The planning artifacts include the Product Backlog, the Sprint Backlog, as well as the Product (or Release) and Sprint Burndowns for tracking progress.
The Product Backlog
In the simplest terms, the Product Backlog is a list of features, functionality, technology and issues. The Product Backlog is:
1. Emergent: At any given time, the Backlog is only partially complete; additional features are added as they are discovered and features that are determined to be low-value are removed.
2. Prioritized: By definition, every item in the Backlog has a priority determined by its position in the list, with the highest priority backlog items appearing at the top.
3. Estimated: Each item in the Backlog is estimated by the people doing to work in terms of effort.
There is one Product Backlog for multiple teams, which is maintained and posted visibly. Anyone can contribute to it but only the Product Owner determines priority. Very often, the Product Backlog is derived from a business plan or vision statement.
Sprint Planning
Sprint Planning
Each Sprint-which is never longer than 30 calendar days-begins with a Sprint Planning Meeting. This meeting is “timeboxed” at eight hours. (Timeboxing is an essential concept in Scrum, in which clear, rigid deadlines are set for most activities.) During Sprint planning, the team and the Product Owner negotiate the portion of the Product Backlog the team will attempt to deliver by the end of the Sprint, as well as a higher level “Sprint goal,” describing the purpose of the Sprint. The Sprint goal(s) should be met, even if the team cannot complete all the selected Backlog items.
Immediately after selecting Backlog items and agreeing on a Sprint goal, the team, either with or without the Product Owner present, decomposes the selected Product Backlog into constituent tasks. This detailed list of tasks is called the Sprint Backlog and serves as the team’s plan for the next iteration.
The Sprint Backlog
The Sprint Backlog includes all the tasks necessary to turn the Product Backlog into working product functionality. Any team member can add, delete or change the Sprint Backlog as work for the Sprint emerges. On average, tasks should represent one day of work each; those that require more than two days should be broken down into separate tasks. During the Sprint, team members volunteer for tasks-they are not assigned to them-and work remaining is updated daily.
The Daily Scrum
As the name implies, the Daily Scrum occurs each day at the same time. Only team members must attend and participate, but anyone is free to observe. During the Daily Scrum, team members discuss progress toward the current Sprint’s goal using three questions:
1. What did I do since the last Daily Scrum?
2. What am I doing until the next Daily Scrum?
3. What are my impediments?
There is the risk that the Daily Scrum will become a perfunctory (and low-value) status report if the ScrumMaster doesn’t encourage active discussion. The ScrumMaster should encourage the team to talk to each other (rather than report to just the ScrumMaster) and use whatever techniques are appropriate to keep everyone engaged.
The Sprint Review
The Sprint Review
The Sprint Review occurs-without exception-on the last day of the Sprint. Here, the Scrum Team and Product Owner have an opportunity to reflect on progress toward current release goals. It also represents another “inspection point” in Scrum’s ongoing inspect-and-adapt cycles. It is not a milestone or deliverable, although what is being inspected probably constitutes both.
During the review, the team demonstrates the functionality developed and the Product Owner accepts or rejects the results based on previously established acceptance criteria. In addition, the team and Product Owner, with the ScrumMaster facilitating, review progress to date and adjust plans in light of emerging conditions.
The Sprint Retrospective
The Sprint Retrospective is the last Scrum meeting, concluding every Sprint. It is an opportunity to reflect on the quality and effectiveness of the team’s processes and propose adjustments. It occurs immediately after the Sprint Review and focuses on strategies for continuous improvement. It is important that the team reflects on how it’s been working so that it can implement improvements going forward.
A final thought
Transforming an organization with Scrum is much more than just about changing people’s titles and renaming meetings. The challenge involves literally learning to look at how work gets done differently. It’s a radical shift in considering how work is managed and one that will be necessarily disruptive, but the results Scrum yields will be equally radical.
Jimi Fosdick is a Certified Scrum Trainer at Danube Technologies. Jimi conducts dozens of public courses around the world each year, helping organizations to surface dysfunction and improve processes through Scrum. Before joining Danube, Jimi spent four years advocating agile approaches to project management-first as a program and project manager, and later as an independent agile and Scrum consultant. During this time, Jimi worked with companies such as CIBER, Razorfish, MTV Networks and Microsoft, helping them transform to more agile ways of working using Scrum.
Prior to these consulting engagements, Jimi spent a decade working in various capacities in software, including as a program manager of software product development and solutions architecture at the Riverside Publishing Company and as a senior staff developer at Polycom. Jimi is a PMI-certified PMP and received his MBA in Project Management from Keller Graduate School of Management. As an undergraduate, Jimi studied mathematics and computer science at Loyola University. He can be reached at jfosdick@danube.com.