Rules to Better Scrum

Everyone who will be involved in Scrum (pigs and chickens alike) should have read and understood the Scrum guide.

Understanding the concepts of Scrum is easy... implementing it is hard!

Scrum may seem complex at first, but it’s simpler than you think. Follow these 8 easy steps to master it.

The Scrum Master plays a key role in the Scrum framework by scheduling and facilitating 3 crucial meetings: the Sprint Review, Retrospective, and Planning. These meetings are essential for reviewing progress, reflecting on performance, and planning future work, helping the team stay aligned and continuously improve.

This is the meeting where the Product Owner accepts or rejects the Product Backlog Items (PBIs) done in the Sprint.

The Team, having prepared for the meeting, presents the PBIs to the Product Owner.

One person, often the Scrum Master, presents a summary to the Product Owner of the PBIs committed at the Sprint Planning meeting and the done PBIs being presented for acceptance. The Team seeks to have more PBIs accepted than originally committed. It is important that the Product Owner knows at the beginning whether The Team believes that they have over or underachieved the Sprint Goal.

At the end of every Sprint, the Development Team performs a Sprint Retrospective, also known as the Retro. The Retro provides an opportunity for the Scrum Team to reflect on what has gone well, what has gone poorly, and what the team wants to change.

Inspect-and-adapt is a key component of the Scrum framework and the Retro gives Scrum Teams an opportunity to learn from their successes and mistakes.

The work to be performed in the Sprint is planned at the Sprint Planning meeting. At the Sprint Planning meeting, the following 3 questions are answered:

• Why is this Sprint valuable?
• What can be delivered in the increment(s) resulting from the upcoming Sprint?
• How will the work needed to deliver the increment(s) be achieved?

Tight project teams have a Daily 'Scrum' every day at the same time.

It was once called a 'stand-up meeting' but that discriminates people in wheelchairs.

It is best to have it standing up, so it's short and to the point. No-one wants to stand around waffling.

In traditional Daily Scrums, each team member answers the same three questions: "What did you do yesterday?", "What are you doing today?", and "Do you have any blockers?". While this format is fine for small teams, it quickly breaks down in larger ones. The meetings become long and repetitive, people zone out while waiting for their turn, and the most important topics often get rushed at the end.

To solve these pain points, use the BREAD format – a structured but flexible approach that scales better and prioritizes unblocking people.

Each step of Scrum is designed to take you towards an outcome, and this is built upon 3 levels of commitment:

The client is generally the Product Owner (PO). They should read the Scrum Guide and watch the Product Owner video to understand their role. It is so important to the success of their project:

Although the team will always strive to complete all the items on the Sprint Backlog within the Sprint, it’s not uncommon for them to not finish all of them. If this is the case, you want to at least make sure that the PO's (Product Owner)’s most important items are done.

Prior to your meeting with the customer you should prepare. Get your Sprint Planning (was Release Plan) email ready, so after the meeting you can adjust and promptly send it.

All good Scrum teams have a backlog. The backlog is built by taking a conversation and recording it as one or more Product Backlog Items (PBIs) (e.g. Azure DevOps) or Issues (e.g. GitHub, JIRA).

You should create PBIs during or straight after the conversation, rather than using emails that may never be entered into the backlog.

Figure: Get typing during a conversation to make the meeting tangible

The Product Owner is responsible for owning the Product Backlog. See the video on "Do you know how to be a good Product Owner?"

Although these requirements come from the Product Owner, it is often the developers who will record these PBIs.

Very often you can come to the end of the Sprint and have incomplete features that either can’t be shipped or can be shipped but don't add any value to the end user or Product Owner. If you are given a feature that is going to take weeks, then split it by following this rule.

Having a clear "Definition of Done" for your team is critical to your success and quality management in Scrum.

The "Definition of Done" is a structured list of items, which exists to ensure that the team agrees about the quality of work they’re producing. It is defined by the team and serves as a checklist that is used to determine completeness.

Every team is different, but all need to agree on which items are in their "Definition of Done".

Always include the relevant URL to your emails, like when you want to request or just made a change to a webpage or document. This way people can easily check the details of the tasks. This is especially important for "Done" emails.

If you are using a task tracking system like Azure DevOps, GitHub, or Jira, also include the link to the PBI/Issue/task/PR for extra information.

When an Issue or Product Backlog Item (PBI) is created, it's important that team members review the title and content to ensure it is clear and correct.

A PBI should not take more than 2 days. Each task under it should not have an estimate of more than half a day (4 hours).

A team knows how many PBIs they can commit to by measuring their velocity. The Team estimates the highest priority PBIs in the Product Backlog in Story Points. It is very important for teams to estimate tasks effectively. There are several methods for estimating:

• Shirt Sizes
• Fibonacci Extended (1-100)
• Fibonacci Original (1-21)
• Doubling
• Thrown