Scrum, day 23: shared team purpose

Today's objective: explain what a team is collectively trying to achieve and use that purpose to resolve competing ideas of success.

Read alongside: Mastering Professional Scrum, chapter 2, focusing on team identity and membership. Consider whose work and decisions are necessary for your product to help its users. Allow roughly five minutes for this companion, plus the book reading.

Four successful people, one unfinished result

Imagine asking four people on the fictional ShiftSwap team what would make the coming week successful. One wants to finish a new screen. Another wants to improve the message service. Elena wants a dependable demonstration for café managers. A colleague working on verification wants to reduce the pile of unchecked changes.

Each ambition is understandable. Together, they do not yet explain what the team is trying to accomplish. The screen could be finished while the messages remain misleading. A smooth demonstration could conceal a problem that still prevents employees from knowing whether their swaps are final.

Shared purpose becomes useful when it changes these choices. It gives people a reason to connect their expertise and a basis for deciding which local achievement matters most right now.

Name the people whose situation should improve

ShiftSwap exists to help café employees arrange eligible shift exchanges and understand the result. Managers also need a dependable approval process without reconstructing conversations across messages and paper notes.

Those people give the team a more useful point of reference than a list of software components. The application includes screens, stored records, messages, and operational support, but users experience a connected service. A request that appears approved in one place and cancelled in another is a product problem, even if each component passed its own narrow checks.

The team's current Product Goal focuses on the first two cafés. That boundary matters. It allows the team to learn from a defined setting before assuming that a solution will work for every location and every staffing policy.

Connect enduring purpose with the current goal

A team might retain a broad purpose for years while pursuing several Product Goals in sequence. “Help employees exchange shifts with confidence” describes a continuing reason for the product. The current goal describes a more specific future state that the team can work toward and assess.

Neither should become decorative wording above a board. When someone proposes support for a third café, Elena and the team can ask whether the current goal has been achieved, whether the proposal helps achieve it, or whether there is evidence for changing direction.

They also need to avoid making a broad purpose so inclusive that every request qualifies. A payroll export may benefit the same employer, but that alone does not establish its importance to the present ShiftSwap goal. Purpose helps focus a conversation; it does not automatically settle every priority.

Test the purpose against a real choice

Two Developers could spend an afternoon polishing a screen that already works. They could instead join a colleague investigating why a delayed message sometimes disagrees with the current request state.

If their success is judged solely by completing their own assigned interface tasks, the polishing work may seem attractive. If their shared purpose includes helping employees trust the final state, the inconsistent message deserves attention. The decision follows from the user consequence and the team's current priorities.

This does not mean every person must abandon every task whenever somebody asks for help. It means the team can explain its allocation of attention through a shared result. Sometimes one person should continue focused work while another helps. The purpose guides that judgment without prescribing an identical arrangement every day.

Define membership through contribution and responsibility

A team identity should help people recognize who shares the work, decisions, and consequences. It should not create a club that excludes the person with an unfamiliar job title or a different employment arrangement.

At ShiftSwap, design, implementation, verification, and operational knowledge all contribute to usable product changes. Someone whose primary skill is testing is not a visitor who inspects the “real team's” output at the end. Their perspective can affect the plan before implementation begins.

The Scrum Guide describes the Scrum Team as a cohesive, cross-functional unit with distinct accountabilities. A practical question follows: can the people who share responsibility for this product actually work together on the decisions needed to finish it?

Notice when membership exists only on paper

Suppose a specialist appears on the ShiftSwap team list but spends most of the week responding to unrelated projects. The team cannot reliably plan a discussion requiring that expertise. Calling the person a team member does not remove the availability constraint.

Radu can help make the situation concrete. Which decisions wait? How often does the waiting affect the Sprint Goal? Is the missing contribution occasional advice, or a capability needed throughout ordinary delivery? Different answers suggest different responses.

The organization might protect more time, change the allocation, help others learn the necessary skills, or reconsider how the work is divided. A team cannot resolve a structural allocation problem merely by writing a more inspiring purpose statement.

Include people without requiring agreement on everything

Shared purpose does not imply that team members always interpret evidence identically. Elena may see an opportunity to learn from a wider pilot. A Developer may see unresolved operational risks. A manager may believe the current workflow already solves the urgent problem.

The purpose gives those disagreements a common subject. What benefit are we trying to create, for whom, and what would we need to know before choosing the next step? People can disagree constructively about the means while remaining committed to examining the result together.

An identity built around being “the team that always delivers everything” would make these conversations harder. An identity built around reliable learning and useful product changes leaves room to expose uncertainty before it becomes a surprise.

Write a purpose that survives a trade-off

Describe your team's purpose in two sentences. Name the people it serves and the change it aims to make in their situation. Then name the current product boundary and one attractive request that falls outside the immediate focus.

Choose a realistic conflict between two local objectives. Explain how the shared purpose affects the decision. If both options still seem equally justified, identify what additional evidence or accountability is needed; a statement of purpose should not pretend to replace those things.

Finally, check who needs to contribute for the chosen result to be usable. Compare that group with the people who can actually participate in the work. Any gap is worth making visible.

Reflection: when someone finishes their own task but the product result remains unusable, what does your team's idea of success encourage them to do next?

Next, day 24 turns shared intentions into observable ways of working.