Scrum is a framework for working through complex problems by creating useful outcomes, examining what has happened and adapting what comes next. It gives a team a shared structure for learning through the work rather than relying entirely on what could be predicted before it began.
At Abstraction Creative, its value is in the quality of the collaboration that structure makes possible. Can people understand what they are trying to achieve? Can they raise a concern while there is still time to respond? Can the work itself help everyone make a better decision?
A full calendar does not answer those questions. The conversations need to change something.
A framework with particular commitments
Scrum organizes work in fixed-length Sprints of no more than a month. A Product Goal provides longer-term direction; a Sprint Goal gives the current cycle a coherent purpose. The Product Backlog holds ordered product work, while the Sprint Backlog connects the current goal, selected work and delivery plan. A usable Increment must meet the Definition of Done. The framework includes Sprint Planning, the Daily Scrum, Sprint Review and Sprint Retrospective within the Sprint. These elements work together, rather than forming a menu of interchangeable meetings. The Scrum Guide provides the complete framework.
Abstraction participates in formal Scrum teams and also draws on selected practices in other engagements. We distinguish those arrangements: borrowing a review format or planning practice does not make the entire engagement Scrum.
That distinction helps everyone understand the commitment. It also leaves room for an appropriate working relationship when a different arrangement would serve the project better.
Give people responsibility they can actually exercise
Scrum identifies three accountabilities: the Product Owner is accountable for product value, Developers create the product, and the Scrum Master supports the team's effectiveness and the establishment of Scrum. The whole team is accountable for a useful Increment. These are accountabilities within the framework, not assumptions about someone's existing job title. Scrum.org's team overview explains the distinction.
When joining a client team, we need to understand how those responsibilities meet the business's actual authority. Who represents competing needs? Who can make a product decision? Which decisions require additional governance, budget approval or specialist advice?
The client retains business authority. That needs to be reconciled with clear product decision-making, not expressed through several people issuing conflicting instructions to the delivery team. A designer or developer should not have to privately arbitrate between departments that have never agreed on what matters most.
We also clarify our own contribution. Participation might involve design, development, content, research or specialist collaboration. It does not automatically mean Abstraction supplies every Scrum accountability, replaces an existing technical lead or assumes authority over the client's organization.
Co-Creation helps explain the relationship we want: people contribute what they know, while responsibility for synthesis, decisions and implementation remains understandable.
Begin with an outcome people can recognize
“Finish the account screens” describes an area of activity. “Let an account administrator invite a colleague with the right level of access” gives people something more meaningful to examine.
The second statement brings questions into view. Who counts as an administrator? Does the invitation expire? What should the colleague understand before accepting? Can the invitation grant permission to spend money? What happens when it reaches the wrong address?
Those questions connect interface design to language, business rules and technical behavior. They also help reveal whether the proposed piece of work is coherent enough to undertake or still contains an uncertainty that needs focused investigation.
We would want the people doing the work to participate in that judgment. An outcome can sound modest to someone looking at the screen while depending on an account model that needs significant attention behind it.
As learning develops, the team can revisit the implementation plan without casually abandoning its purpose. In formal Scrum, changes must not jeopardize the Sprint Goal; scope can be clarified with the Product Owner as understanding improves. That distinction is part of the framework's Sprint guidance.
Inviting someone into a shared account
When customers share a company account, we can use the invitation of a colleague as a meaningful piece of product work. We explore it with the trade-supply team, connecting the intended improvement with the account policy and the support conversations it needs to change.
A useful first outcome could be an invitation that gives a colleague access to product information and saved lists, while keeping purchasing permissions separate. That boundary would need agreement with the business. A user interface cannot resolve an unsettled policy simply by adding a dropdown.
The team could examine the complete encounter: creating an invitation, receiving it, understanding the access offered, accepting it and knowing where to go next. It would also consider expired invitations, existing accounts and attempts by someone without the necessary authority.
Identity and Access Management contributes the underlying permission questions. Content contributes the explanation. UI/UX contributes the interaction, and development connects the behavior to the account system. The result depends on those contributions working together.
Suppose a working review reveals that “viewer” means different things to the staff and their customers. Some understand it as access to the public catalog; others expect access to negotiated prices. The next useful decision may concern account visibility, not another screen.
The team would need to distinguish a defect in the agreed behavior from a newly discovered product need. A defect cannot be renamed “future learning” to make the work appear complete. A new need can be considered alongside other priorities, with its implications made visible.
The invitation becomes a shared product question, bringing account policy, interface language and working behavior into the same conversation.
Two kinds of reflection
A Sprint Review examines the product outcome and its implications with stakeholders. It should support a conversation about direction rather than serve only as a polished walkthrough. Scrum.org's Sprint Review discussion emphasizes shared understanding of product priorities, not stakeholder approval of the next Sprint Goal.
In the invitation example, useful review questions might include whether the access distinction fits the business and what the newly working behavior makes worth pursuing next. Showing the flow helps make those questions concrete. It does not substitute for observing intended users where user research is needed.
A Sprint Retrospective turns attention to how the team works and what could improve quality and effectiveness. That is a different purpose from deciding what the product should do. Scrum.org's retrospective overview describes that focus.
The team might notice that questions about permissions reached the right person only after development had started. A useful response could be to involve that decision-maker earlier when refining access-related work. The lesson is about an absent connection, not finding someone to blame for asking a question late.
Design Facilitation can help make these discussions useful: a clear purpose, relevant voices, room for disagreement and a decision or action people understand afterward.
Be precise about what is done
The Definition of Done makes the quality conditions for an Increment explicit. Work meeting it can be delivered; a convincing demonstration alone is not the standard. Scrum.org's explanation connects Done to a shared understanding of completion and quality.
For the account invitation, implementation review might include permission checks, accessible interaction, relevant failure behavior and the instructions support staff will need. Those are illustrative considerations, not a complete testing standard or a promise that checking a list establishes security.
We would also distinguish a completed improvement from evidence that it creates the intended customer benefit. Software can meet its agreed quality conditions while leaving us with further questions about adoption, comprehension or usefulness. Those questions deserve appropriate investigation, not a declaration that the calendar has settled them.
Operating and release responsibilities remain important. A team needs to know who coordinates the change, what supporting information must be ready and how to respond if the actual behavior differs from expectations. Scrum does not remove the need to understand the system being changed.
Keep the wider inquiry alive
Our expression of Design Thinking remains:
Discover → Define → Explore → Design / Develop / Market → Learn → Advance → Discover
Scrum can help organize delivery within that continuing inquiry. We do not map each stage to a separate Sprint or suggest that research and design stop when development begins. A product question may need another conversation, sketch or experiment while implementation is underway.
A design sprint is a distinct approach to exploring and testing a proposed experience. It is not simply a Scrum Sprint carried out by designers. Likewise, Agile Development describes a broader approach, while Scrum provides a particular framework.
Connections should help us choose thoughtfully. A method should not make it harder to notice what the work actually needs.
Design Sprints serve a different purpose: focused exploration and testing of a proposed experience before a larger commitment. A development Sprint and a design sprint can inform one another, but they should not be treated as interchangeable promises.
Make progress understandable beyond the meeting
When Abstraction contributes to a team, we want the reasoning to remain available. Relevant decisions, known limitations, operating instructions and living workbooks can help the client retain the knowledge developed along the way.
We agree what needs to be recorded and who will maintain it. A change to the product may require a corresponding change to the explanation a staff member relies on. Continued collaboration can support that care when it is part of the agreed scope.
If your team already works with Scrum, we can discuss how our contribution fits its responsibilities and product needs. If you are still deciding how to organize the work, we can begin with the people, decisions and uncertainties involved rather than assigning everyone a new label.
You should be able to understand what we are making together, why it matters and where your knowledge can help shape it.