Scrum Mechanics – Introduction to the Basic Scrum Engine

If you asked a few people in the Scrum community to define Scrum, you might be surprised to receive a different answer from every person. To me, it’s a management paradigm, a set of guiding principles, a key to employee retention, the embodiment of good application of organizational psychology, and just plain common sense. But if you polled the same group about the basic mechanics of Scrum, you’d notice much less discrepancy among their responses.

Scrum’s mechanics have three major parts: roles, meetings, and artifacts.

Three Scrum Roles

Team members:
Team members are people who actually do work and create stuff in the Scrum process. They come from different backgrounds and areas of specialization and should include all of the knowledge and skills necessary to produce the output they’re expected to produce. Common team members include developers, architects, QA engineers, TDD engineers, UI designers, and business analysts. Less common but possible team members might include marketing staff, technical writers, and administrative staff.

These professionals work together on a self-organized team, responsible for delivering on their commitments every sprint. Teams commonly consist of five to nine members in size and, ideally, should be co-located.

ScrumMasters:
ScrumMasters are individuals (usually one per team) who make sure the team is not impeded from completing its work. They don’t do this through management or enforcement, but rather by reminding the team of the Scrum process while removing any obstacles preventing the team from accomplishing its sprint goal. Their job is to pay attention to the team’s needs and meet them whenever possible. ScrumMasters may help product owners with planning, procure resources for their team, identify and remove distractions, and remind the team of the Scrum process. They are facilitators, not managers.

Product Owners:
Product owners are responsible for telling the team what the business needs and negotiating the amount of work a team will take on in a single sprint. They are responsible for documenting and prioritizing the needs of the business in a product backlog (or list of things the team should do). The product owner is also responsible for inspecting a team’s work at the end of each sprint and determining whether or not it meets the acceptance criteria. Of course, a product owner’s authority comes with plenty of responsibility, too. As Danube CST Michael James puts it, “The product owner is the single wring-able neck.”

Four Meetings of Scrum.

Planning Meeting:
The planning meeting is a negotiation. During this meeting, the product owner presents the backlog to the team and asks the team to deliver the highest priority backlog items in the next sprint. The team then evaluates the product owner’s requests and tells the product owner how many backlog items can be reasonably completed in the next sprint. Over the course of a conversation, an agreement is reached between the team and product owner on what will be completed in the next sprint.

Stand-up Meetings or Daily Scrums:
Daily Scrum meetings occur each day for 15 minutes with all team members and the ScrumMaster present. Each team member reports what they did yesterday, what they will do today, and what impediments stand in their way. This meeting ensures that all team members are on the same page, aware of what work others are tackling and the challenges impeding them.

Review Meeting:
At the end of the sprint, the product owner and team gather again. In this meeting, the team demonstrates to the product owner what it created during the previous sprint. The product owner then determines whether the backlog item is done or not done, based on acceptance criteria agreed upon in the planning meeting. Completed backlog items are counted toward a team’s velocity and incomplete ones (even if only 2% incomplete) are put back in the product backlog for consideration in a future sprint.

Retrospective Meeting:
The retrospective meeting is a time for a team’s members to check in with one another and candidly assess their performance. In retrospectives, the team and the ScrumMaster talk about how their process is going, what could be improved, and how they’re working together. This meeting is about team health and communication, not about the product itself.

Three Artifacts in Scrum

The Product Backlog:
Essentially a product backlog is a list of work that needs to be completed at some point, during a project. Ideally, it is comprised of well-written backlog items with clear criteria of when each is done, prioritized by the product owner into an order that reflects the needs of the business.

The Sprint Backlog:
The sprint backlog is a list of work that has been committed to by the team during the Sprint Planning Meeting. It should be a list of backlog items in priority order with clear criteria as to when the product owner will consider each item done. The team should complete every item in the sprint backlog by the end of each sprint.

The Product:
The product is the ultimate measure of progress for a team. The product reflects all work completed to date that a team or group of teams has created and possesses clear business value for the organization.

Other Artifacts:
In many implementations of Scrum, you’ll find artifacts like team impediment backlogs, organizational impediment backlogs, sprint burn-down charts, product burn-down charts, and others.

That’s everything (and just the tip of the iceberg)

Simply, if you’re using all of the above roles, meetings, and artifacts, I’d say you’re probably doing Scrum. If you’re missing any of the above, you’re not. Yes, Scrum is that simple, but it is not that easy. Using Scrum basics in a disciplined fashion is no small task and forces organizations and individuals to question everything about their current and former practices. The good news is that teams who are committed to Scrum are some of the most successful I’ve ever seen. So if you’re ready for a big challenge that yields big results, read on.

Download the PDF version: Scrum Mechanics blog

Posted in Agile

Leave a Reply

Your email address will not be published. Required fields are marked *

*