Agenda Templates - Docket

Run Fun and Effective Meetings with Docket

Docket is a meeting-focused workspace for collaborative agenda creation, decision documentation, and action item tracking.

Try Docket with your meetings for free.

“Docket has quickly become essential to doing our best work at Studio Science. Meetings are critically important to the services we provide clients, and having a platform dedicated to making meetings more effective, collaborative, and structured is game changing.”

Steve Pruden, CEO at Studio Science

“Docket helps us build better agendas, easily share notes, and follow up on action items. We have noticed our meetings have better preparation and follow through since partnering with Docket.”

Roger Deetz, VP of Engineering at Springbuk

Scrum Best Practices

“Scrum” borrows its name from a rugby term. The two teams reset for a play by interlocking team members, face down, in a big huddle and scrambling for the ball by hand.

As applied to software development (and, increasingly, other disciplines), Scrum strives to be a little less chaotic. In fact, the whole point of Scrum in a nutshell is to find simplicity in complexity by breaking cumbersome, abstract tasks into actionable, digestible chunks.

“Scrum” refers to a framework to do just this, as outlined in the “Scrum Manifesto.”

To identify Scrum best practices, ways in which they intersect with the 3 Agile practices, other Agile best practices and Agile testing best practices, as well as to help prepare for scrum master interview questions, it helps to know what Scrum is. Here is a complete Scrum guide to introduce the concept.

When was the Scrum Guide Written?

The first version of the Scrum Guide (pdf) was written between 2008 and 2010. It’s easy to find a Scrum Guide 2017 pdf, Scrum Guide 2018 pdf, and Scrum Guide 2019 pdf.

Scrum Guide 2019: What Is Scrum?

Scrum is a kind of Agile Process Framework, originally conceived to develop intricate or groundbreaking software. Scrum is just one example; kanban is another.

Like other agile frameworks, Scrum is designed as 3 agile principles—to be lightweight, adaptable, and iterative. Agile processes focus on continual improvement and flexible responses to changing problems with the ultimate goal being early delivery of results such as the requested product, system, etc.

Scrum takes two things for granted including requirements volatility and unpredictability.

Trademarks of Scrum implementation include:

  • Three Well-Defined Roles. See below for detailed descriptions.
  • The Sprint: A time-boxed unit of work, usually two weeks long but never longer than a month.
  • Self-Organization: No “project manager” holds ultimate authority.
  • Empirical Approach: Processes adapt in response to the evidence.
  • The Scrum: A daily, “stand-up” meeting to keep the project on course.

With SAFe Agile ceremonies, Scrum defines how many artifacts, aka “Scrum Artifacts,” radiate information on the project. These include:

  • Product Backlog: An evolving document that enumerates the needs of the “stakeholders” in the project. The document must evolve because Agile and Scrum principles assume the stakeholders’ needs and requests will evolve.
  • Sprint Backlog: An evolving document that enumerates the goals and actions to be taken within the current sprint. Scrum principle assumes that unexpected obstacles will arise, necessitating evidence-based changes of course.
  • Burndown Chart: A visual aid graphing the amount of work estimated to remain before the project is complete.
  • Product Increment: A unit of completed project deliverable—for example, a unit of finished code.

Scrum Principal

Even experts disagree on how many Agile and Scrum principles exist.

However, a complete list of Scrum pillars might include:

  • Incremental: A large project gets broken down into manageable increments, efforts organized into “sprints.”
  • Contextual: The parameters of the project inform the process, not vice versa.
  • Transparent: Everyone knows what everyone else on the Scrum team is up to, resulting in complete accountability.
  • Empirical: The Scrum process flow adapts to evidence, not to the ego.
  • Self-Organizing: The Scrum team operates by consensus, not by top-down dictates from a project leader.
  • Collaborative: Scrum teams work together to achieve results greater than the sum of the individual members.
  • Focused: Work is limited to manageable tasks, with controls in place to stave off distractions.
  • Experimental: Scrum team members must feel free to try new things.
  • Prioritized: Scrum practices dictate the delivery of maximum value, right from the start of the project.
  • Time-Boxed: No open-ended increments. Scrum increments are strictly time-boxed at regular intervals.
  • Iterative: Operations and actions repeat in cycles, with evidence-based improvements and corrections applied to each cycle.

Scrum Roles and Team

While Scrum defines how many roles, events, and artifacts may be attributed to a project, there is also the Scrum team. A Scrum team usually consists of no more than ten members, grouped into three roles:

Product Owner

The Product Owner serves as the liaison between the Scrum Team and the customers or stakeholders, with an eye toward the “business side” of the project.

Excellent communication skills are critical for a Product Owner, as changing customer or client needs get transmitted from the stakeholders to the team via the Product Owner, as does the news of unexpected obstacles or course changes in the opposite direction.

A Product Owner must also exhibit empathy, as each stakeholder may have different goals, expectations, and backgrounds. The Product Owner must identify those needs and communicate them to the team, helping negotiate priorities and bridge gaps. Similarly, team members may encounter frustrations that need to be addressed before they can move on to the next task.

Other tasks that fall under the purview of the Product Owner include:

  • Status updates to stakeholders.
  • Release announcements.
  • Maintaining a transparent, clear product backlog. 

Despite the proprietary name, the Product Owner is not the project manager or team leader. Scrum teams are self-organizing by design. The Product Owner merely helps build consensus and negotiate priorities, with an eye to the stakeholders’ needs.

Scrum Master

“Scrum Master” is another imperious-sounding role that nevertheless does not denote absolute authority over the team. Sometimes referred to as a facilitator or “servant-leader” of the Scrum team, the job of the Scrum Master is to remove distractions and allow team members to focus on the tasks at hand. Well-versed in Scrum principles and scrum master tips and tricks, the Scrum Master guides the team to follow those principles in pursuit of a favorable outcome.

This involves steering the team to empirical thinking, without expectations of certainty, static project parameters, or predictability.

Here’s how to be a good Scrum Master:

  • Educating the team and stakeholders on Scrum principles and select Agile development best practices.
  • Facilitating self-organization within the team.
  • Helping maintain clear Scrum Artifacts like the product backlog.
  • Keeping the Scrum process free of distractions through agile best practices project management.

Knowing Scrum Master strengths and weaknesses as well as Scrum Master best practices can help your team select the best scrum master and help guide the Scrum Master first 30 days on the job. A struggling Scrum Master could easily let the project go awry. Pay attention to the Scrum Master do’s and don’ts in the Scrum Alliance Scrum Guide. More guidance can be found in Scrum Guide audio, Scrum Guide HTML, scrum best practices PDF, scrum best practices PPT, scrum fundamentals PDF, “Hackernoon What Makes a Good Scrum Master,” or Scrum Implementation PPT,

Development Team

This role gets misunderstood. Engineers, architects, researchers, analysts, statisticians, and other specialists do not usually think of themselves as “developers.” Yet for the purpose of the Scrum framework, all of these specialist, typically 3-8 per team, may be part of the “Development Team,” in primary or supporting roles.

Any team members not designated as Product Owners or Scrum Masters are by default on the Development Team, usually limited in size so no more than 10 members sit on any Scrum team.

Scrum Ceremonies

It’s already going out of style to refer to Scrum events as “Scrum Ceremonies,” the same as with Agile or Kanban ceremonies. Whether you call them “events” or “ceremonies,” however, four major meetings characterize the Scrum framework. Scrum ceremonies are optional, but highly recommended. So what are the four Scrum Ceremonies and what is the Scrum practices order?

Scrum Ceremonies Timeline:

Sprint Planning

At the Sprint Planning meeting, the team reviews sprint principles and sets goals and objectives for the coming Sprint. All Scrum team members participate. The 1-2 hour meeting includes a rundown of the product backlog by priority, an estimate of the time needed to complete backlog priorities, and a “Sprint forecast” of progress to be made during the Sprint. This is sometimes referred to as “Scrum ceremonies grooming” or “Agile ceremonies grooming.”

Daily Scrum

The Daily Scrum is the heart of the Scrum process. The whole team meets every day for a short (15-minute max) meeting, so quick that it often gets called a “stand-up” meeting—no time to sit and get comfortable, there’s work to be done.

This is not a deep-dive meeting, just a light and fun chance to give an honest report of what you did yesterday, what you plan to do today, and any obstacles you encountered.

The transparency of the Scrum contributes to accountability—no one wants to have to report at the Scrum that they accomplished nothing they set out to yesterday and for no good reason.

Sprint Review

At the end of the Sprint, the Scrum team convenes to show their work and share results and challenges. It’s a time for congratulations, constructive feedback, and groundwork for the next Sprint.

Sprint Retrospective

Whereas the Review examines the results of the process, the Retrospective examines the process itself, assessing what worked and what didn’t, congratulating successful practices and offering constructive criticism to improve for the future. Neither post-sprint meeting is a time for complaining or the blame game. Agile processes are iterative, evolutionary, and constantly improving. Anything that went wrong this Sprint is a map of how to do better in the next Sprint.

Scrum Best Practices

Now that we know about Scrum and its principals, players, and agile ceremonies, we can assemble a list of Scrum and Agile Best Practices for teams, to include:

  • Self-Organizing Team. Neither the Scrum Master nor the Product Owner takes a directive or authoritative role, except to communicate stakeholder directives or enforce Scrum principles.
  • 15-minute Scrum (stand-up meeting).
  • No complaining, blame game, or non-constructive criticism. Only constructive criticism and congratulations.
  • Team members transparently describe what they are going to do, fostering accountability.
  • Teams of 3-10 members max.
  • Co-location OR close digital collaboration to participate in daily Scrums.
  • 2-week sprints, one month maximum, with planning at the beginning, review and retrospective at the end.

In support of your agile scrum process, use a tool like Docket to orchestrate, facilitate, and organize your meetings.

Docket is no longer in service. Thank you to all of our customers for letting us help you make meetings awesome!