Scrum, day 20: choosing practices for a purpose

Today's objective: distinguish a Scrum requirement from a supporting technique, then choose a practice according to the problem it is meant to solve.

Read alongside: Scrum: A Pocket Guide, fourth edition, §§3.3–3.6: the sections on Product Backlog refinement, User Stories, Planning Poker, and eXtreme Development. Focus on one technique you recognize and one you have not tried. Allow roughly five minutes for this companion, with additional time for the book sections.

Inspect the rules your team has accumulated

A new colleague joins the fictional ShiftSwap team and asks how it works. Someone explains that every backlog item must use a particular user-story sentence, every estimate must be a Fibonacci number, and the Daily Scrum must follow three fixed questions.

Another colleague adds that refinement happens only on Wednesday and that a new item cannot be discussed until its template is complete. These rules are familiar, but the team has not recently examined where they came from or whether they still help.

Some describe optional techniques. Some describe local agreements. Some may now obstruct the very conversations they were introduced to support. The team needs a way to distinguish the framework's requirements from its own implementation choices.

Keep the required purpose visible

The Scrum framework defines accountabilities, events, artifacts, and commitments. It leaves room for techniques that help a team work within those elements. The Scrum Guide is the reference for what the framework actually requires.

For example, Product Backlog refinement is an ongoing activity that makes items smaller and more precise. A weekly meeting can support that activity, but the meeting is not a separate mandatory Scrum event. Useful clarification can happen when a relevant question arises.

Similarly, the Daily Scrum has a defined purpose and timebox, while the Developers choose its structure. A three-question round may help some teams. It becomes a problem if people recite updates without adapting the plan toward the Sprint Goal.

Changing a supporting technique should preserve the required purpose. Cancelling every refinement conversation because the Wednesday meeting feels unproductive would leave the underlying need unresolved.

Test a user story by the conversation it enables

The team writes a candidate item this way:

As an employee, I want to see why my request was declined so that I can choose what to do next.

The sentence makes the user and intended benefit visible. It does not resolve all the relevant behavior. What should appear for an older request? Which explanation is appropriate for an employee? What next actions are valid after the shift has passed?

A few concrete examples may reveal more than repeatedly polishing the sentence. A workflow sketch or a direct conversation with a manager could help too. The format should support shared understanding.

User stories are a complementary practice, not a required format for every Product Backlog item. Scrum.org's discussion of complementary practices makes that distinction. Maintenance, technical improvements, and investigation work should be described in a way that helps the relevant people understand and evaluate them, without forcing an artificial narrative.

Use estimation to expose different assumptions

During a Planning Poker discussion, one Developer considers the decline explanation a small change. Another sees substantially more work. The team could repeat the vote until the numbers converge or average them into a seemingly precise answer.

Instead, it asks what each person included. The smaller estimate assumes every request already contains employee-facing text. The larger estimate includes examining older records and keeping internal notes separate. The disagreement reveals an important difference in understanding.

That conversation is useful even before the team agrees on a size. It may lead to clearer examples, a smaller item, or an investigation. Producing a number while preserving incompatible assumptions would offer little help in planning.

Story points and Planning Poker are optional techniques. The Developers remain responsible for sizing the work they will do, but Scrum does not mandate a particular scale. Any chosen approach should help them reason about the work and its uncertainty; the unit itself does not measure product value.

Choose technical practices for a concrete quality problem

The team also considers how to prevent delayed notifications from describing an outdated state. Pairing could help spread knowledge of the message service. Automated checks could make the failure easier to detect after changes. Frequent integration could reveal incompatible assumptions earlier.

Each practice needs a purpose in this product. Pairing for every task without considering the learning or coordination need may waste attention. A large test suite that misses the important message sequence may provide misleading confidence. Integration that never checks the complete behavior can still leave serious gaps.

The question is what the practice helps the team observe or improve. The shared Definition of Done and the need for a usable Increment remain relevant regardless of the particular engineering approach selected.

Compare practices using the same questions

ShiftSwap makes a small record for the techniques it wants to evaluate:

The table does not prove which practice is best. It makes the team's intention explicit enough to inspect. A technique can be useful now and need revision as the team or product changes.

Review one local rule

Choose a rule your team follows. Identify whether it comes from the Scrum framework, an organizational constraint, or a locally chosen practice. If you are unsure, check the actual source rather than relying on how confidently someone states it.

Describe the problem the rule is meant to solve and the evidence that it helps. Propose one small change if the current practice adds effort without supporting its purpose. Keep any genuine framework or organizational requirement visible while considering alternatives.

Reflection: if your usual tool or template disappeared tomorrow, could you explain what information and decision it was meant to support? That explanation is a useful guide to choosing a replacement.

This completes the first twenty companions. The next part uses Mastering Professional Scrum to examine improvements in team practice. Begin with day 21: assessing today’s practice.