What is Scrumand?

Scrumand – when organisations extend the Scrum framework

The Scrum Guide defines the “rules of the game” of Scrum and names three responsibilities, five events and three artefacts. The use of elements that are not described in the Scrum Guide and extend the framework or its application is referred to as Scrumand.

The term is derived from “We use Scrum and …” and is based on the phrase “We use Scrum, but…”, which indicates the omission of individual elements – a so-called Scrumbut. Scrumand and Scrumbut are virtually “siblings” in spirit.

The intention of a Scrumand is usually to adapt the framework to the context of an organisation and thus corresponds to the understanding of the two Scrum authors¹.

Types and examples of Scrumands

The range of possible Scrumands is very wide, as extensions can, for example, relate to

• the accountabilities and tasks of the Product Owner, the Scrum Master and the developers,
• the execution of events (Sprints, Sprint Planning, Daily Scrum, Sprint Review or Retrospective),
• the use of artefacts (Product Backlog, Sprint Backlog and Increments) or
• the use of commitments (Product Goal, Sprint Goal or Definition of Done).

Here are a few examples:

• Instead of a Product Owner, a project works with a Product Owner Team or a Proxy Product Owner.
• In addition to the Daily Scrum, a Weekly Standup Meeting is held to further synchronise team members or to review interim results.
• In addition to the artefacts, customer specifications and requirements specifications, lessons learned templates and protocols are used.
• In addition to the commitments, a definition of readiness and individual target agreements are used.

The list can easily be extended, especially if you classify all tools that are not explicitly mentioned in the Scrum Guide but are used in organisational reality as Scrumand: user stories, acceptance criteria, velocity, story points are such tools.

And last but not least, Scrumands can also result from the combination of some non-Scrum practices with the Scrum framework: “We do Scrum and OKR”, “Scrum and DevOps”, “Scrum and Design Thinking” or “Scrum with Kanban” aka Scrumban.

Are Scrumands good or bad?

Some discussions give the impression that adapting Scrum is a bad idea. Nobody gets an asterisk on their report card if a development is carried out 100% according to Scrum. Scrum is a framework and “only” provides a framework with tools and descriptions that can be helpful in the iterative development of complex products and services. Anyone who wants to customise Scrum can and should do so. Ideally, however, users should know what they are doing – a Scrum case, for example, is rarely expedient – and they should check the usefulness of the extensions over time.

So are Scrumands good or bad? There is no universal answer to this question.

Impulse to discuss:

How likely is it that organisations will implement Scrum 100% as described in the Scrum Guide?

Notes:

You are welcome to share or link to the content on this page.

[1] Ken Schwaber and Jeff Sutherland are the originators of Scrum. They do not see the Scrum Guide as a manual for implementing Scrum, but merely as a description of the framework. Various methods, processes or techniques can be used within the framework. Each element described in the guide serves a specific purpose that is essential to the overall value and results achieved with Scrum. The context-dependent extension of the framework is therefore obvious and fundamentally understandable.

Here is a nice appeal that explains how organisations can move from a Scrumbut mindset to a Scrumand approach.

Here you can find a free Scrum whitepaper with everything you need to know about the framework at a glance.

And here you can find additional information from the t2informatik Blog: