The Scrum Framework: You are doing it wrong!

How should we implement Scrum?

What are various roles and ceremonies of Scrum?

What is Scrum Methodology?

What meetings are required by Scrum?

Scrum is the most popular Agile Framework. Almost every software development team in the world is using some aspects of Scrum framework in some shape or form. However most Scrum implementations that I have seen are missing some crucial parts of the recipe preventing them from achieving the exceptional results promised by Scrum.

I’ve decided to write this article, providing a concise summary of Scrum framework and how I believe it really should be implemented.

What is Scrum?

This is Scrum:

The Scrum Flow

Piece of cake! Isn’t it? Now let’s look at each artefact, role and ceremony in more details:

Product backlog

Product backlog is an ordered list of various work item that needs to be done. These work items are called Product Backlog Items (PBI). Items at the top of the backlog have higher priorities and items at the bottom of the backlog have lower priority. No 2 items have the same priority. Every item has more priority than the item below it and less priority than the item above it. The product backlog is not a queue and can be constantly reprioritised and changed by the product owner.

Items at the top of the backlog are more refined and are more ready for the team to start working on and items lower in the backlog are larger and more abstract. PBIs can be various things including but not limited to requirements (user stories), bugs, Spikes and research tasks, tech debt, etc.

Product Owner

Product owner is the person ultimately responsible for the product. They steer the development by prioritising the work. Product owner has content authority of the user stories. Based on the input from the stakeholders and the product/team vision, the product owner makes decision on the work that needs to be done. Product owner is responsible for defining the “why” and the “what” but not the “how”.

Product owner not the boss of the team, they are just another team member like everyone else. They are however the boss of the product backlog. They own the backlog. They decide what gets built next by prioritising the backlog.

The most important attributes of product owner are:

  • Domain Expert (e.g. understand the product really well)
  • Available (e.g. sitting with the team)
  • Stakeholder manager (e.g. ability to say no to multiple directions)
  • Empowered (e.g. ability to make important decisions independently)

The best analogy for product owner is “The Doctor” form the “Doctor Who” show.

The Product Owner

He has the weight of the world on his shoulder.

He prioritises. Some lives need to be sacrificed to save the universe. And the product owner needs to live with those decisions for the rest of his life.

There is so much on his mind. So many responsibilities, so many balls to juggle. So little time. Needs a TARDIS to go back in time to finish those jira cards just in time.

He has made so many mistakes but at the end of the day he has saved the product and the universe so many times.

He is the best negotiator in the world. Can negotiate Daleks and Iron Men out of blowing up the planet

He knows almost everything. He has breadth of knowledge.

He finds information and provides it in a consumable format.

He is always available any time anywhere. He has a TARDIS.

And most importantly he is empowered to make decisions.

The development team

The development team or the developers are the people who build the product. Developer in the context of Scrum does not mean a computer programmer. It means anyone who participates in the development of the product. For example Programmers, Testers, UX designers, Business analysts, Tech writers, Release Leads, Architects, etc are all developers. Basically everyone on the team except the Scrum Master and the product owner are developers (remember this for your PSM exam).

are responsible for defining the “How”, but they can also contribute and help
product owner on the “What” and the “Why”. The Dev team needs to remain stable
over long periods of time. We can’t add/remove developers to the team at will.

best Analogy for the Dev team is the Guardians of the Galaxy.

The Development Team

are NOT super heroes. They don’t
have super powers. Except for maybe Groot.

have T-shaped skills. Highly skilled at one thing but also a little skilled at
a few other things

may have their differences but they collaborate really well.

cover for each other.

may look selfish at first but they are prepared to die for each other.

all have their quirks, but do the right thing at the end of the day.  

most importantly they do whatever it takes, whatever it takes, to get the job

Scrum Master

Scrum Master is the Master of Scrum. When we say someone is the Scrum Master
does it mean everyone else are the Scrum Slaves? No, “Master” here refers to
mastery. It means the Scrum Master is highly skilled at Scrum. They are the
Scrum Coach for the team. The Scrum Master is the team facilitator and the
remover of impediments.

Masters are servant leaders. It means they lead without having authority, just
like Nelson Mandela, Mahatma Gandhi, and many other servant leaders in history.
They persuade rather than using authority and lead rather than manage. The Scrum
Master is not the boss and the team don’t report to the Scrum Master.

Scrum Master is more of a “Servant” rather than a “Master”. They need to server
the team and make sure the team gets whatever they need to work at optimum

best analogy for the Scrum Masters are Jedi Knights from the Star Wars Saga

The Scrum Master

Scrum Master is the glue for the team.

has great relationships with everyone.

is a facilitator.

sure the processes that the team agree upon are followed.

is the impediment bulldozer.

users a light-sabre to open up the path for storm developers (storm troopers)
to move forward into enemy territory.

is diplomatic but not political. Witty and clever but righteous.

travels across the galaxy to facilitate and remove impediments.

most importantly he uses “the force” to sense impediments before they are even

Sprint Planning

the Sprint Planning meeting, the team plans for the sprint. The sprint planning
is time boxed maximum of 4 hours for 2 week sprints. This meeting happens at
the beginning of the sprint. At this sprint we talk about how much work can be
done this sprint and how the chosen work will get done.

this meeting the team starts picking up PBIs from the top of the product
backlog. They discuss each item and clarify questions with the product owner. They
estimate the PBI if not already estimated and start thinking about implementation
on a very high level and not too much in technical details. Then they will move
to the next PBI from the product backlog. The team repeats this until they feel
they are at capacity.

work that the team plans to deliver this sprint is called the Sprint backlog. Then
based on the work that the team has picked up in the sprint backlog, they
construct a Sprint goal.

the team commits to deliver the sprint backlog by the end of the sprint. And the
product owner commits not to change anything in the sprint backlog during the
sprint. If the product owner makes any changes it will void the team’s

that the Scrum Guide has removed the word “commitment” and replaced it with “forecast”.
I personally still prefer to call it commitment rather than a forecast. At the
end of the day, every team needs to assess this in their context to see if they
are happy to consider the sprint backlog as a commitment or prefer to think of
it as a forecast.

Sprint Backlog

mentioned above the sprint backlog is the plan that the team comes up with for
the sprint. The sprint backlog is owned by the developers. The order of items
in the sprint backlog is decided by the dev team not the product owner (unlike
the product backlog). The product owner cannot make any changes to the sprint
backlog. If the product owner needs to absolutely make changes to the sprint
backlog in certain circumstances, they will void the commitment/forecast of the
team to deliver what they said they will in the sprint.  

Backlog refinement

refinement (A.k.A. Backlog Grooming) is the process of refining and preparing
the PBIs for the upcoming sprints. Typically there is a backlog refinement
meeting to talk about and estimate the PBIs prior to the sprint planning. The better
we prepare and refine the PBIs before the planning meeting the shorter and
easier the planning meeting becomes.


is a short timebox where the team refines, builds, and tests PBIs. At the end
of the sprint a potentially shippable product implement must be produced. Typically
sprints are 2 weeks but it can be really any length, I have seen 4 week
sprints, 3 week sprints, 2 week sprints, 1 week sprints and even 2.5 day
sprints. It is a decision that needs to be made according to the context.

that once we set the sprint length we don’t want to change it and we want to
keep the cadence.

sprint the team iterates and goes through the same process again, incrementally
delivering potentially shippable product increments.

Daily Scrum

Scrum or Daily Standup is a short meeting that happens every day while standing
up next to the team kanban task board. The Daily stand-up is timeboxed to
maximum of 15 minutes but ideally you want to finish your standup in 5 minutes.

daily Scrum is not a problem solving venue. Neither is a status update. The daily
Scrum is a venue primarily for identifying impediments. It is also a venue for confirming
if we are still on track with achieving the sprint goals.

are 3 questions that everyone needs to answer in the daily stand up:

What did I do yesterday?

What will I do today?

do I have any impediments?

daily Scrum is followed by a meet after in case some people need to discuss
anything specific or get into more detailed conversation

is quite common that developers decide if they are going to pair with anyone
during the standup.

Potentially shippable product
increment and the definition of done (DoD)

team will have a definition of Done (DOD). This is to align what done means. So
we are not going to have conversations like is it done or is it done done?

team needs to write the DoD, print it, and put it on their wall. The DoD
defines what a potentially shippable product increment means. Ultimately Done
in Scrum means released to customers. However in most cases it is not practical
to release to customers within each sprint. For a start, most teams do not have
continuous delivery pipeline. Even if they did have it, deployed to production
does not necessarily mean released to customers. This is because typically
there are other activities such as documentation, customer communication, marketing,
compliance and many other activities that need to be done before new features
are released to customers.

“potentially shippable” in potentially shippable product increment is referring
to this. That shipping the product is a business decision. The team needs to
make sure it is potentially shippable and the business makes the call to ship
it or not.

very common Definition of Done that I see all the time is deployed on staging
and approved by product owner. However Scrum teams need to strive to move their
done to mean released to customers. Over time they need to bring those extra activates
within the sprint and the capabilities of the team to make sure they can go all
the way until value is realised by the customer and only then call it done.

Sprint Review

sprint review is the event that the team (including the product owner) demo the
work they have done during this sprint to a wider stakeholder group. The primary
purpose of sprint review is to inspect and adapt the product and get feedback
from the wider stakeholder group.

let be quite clear. Sprint review is
not just a “showcase”.
Please stop calling sprint review “showcase”.

sprint review a showcase trivialises the review to a just a demo rather than a collaborative
session where stakeholders provide feedback. It is a review of the potentially
shippable product increment not a showcase of what we did in the sprint.

Sprint retrospective

the event where the team focuses on themselves and the process. They inspect
and adapt the previous sprint. During the retrospective the team looks at the
sprint and brainstorm on what to keep and what to change. Every retro needs to
have 1-3 actions. The teams need to come up with experiments and implement
them. Then review their experiments in future retro. We want to inspect and
adapt in short small cycles that is why we do a retro every sprint.

Scrum theory

is based on empirical process control theory. Empiricism is what the scientific
method is based on. It means in scrum every opinion remains a hypothesis until
it is validated.

The Scrum Theory
Scrum Theory

order to have empirical process control we need to have transparency,
inspection and adaption. It means we come up with hypotheses, we keep a transparent
environment, we inspect, and based on our learning, we adapt.

is designed in a way to maximise transparency, inspection, and adaption. Ken
Schwaber, one of the original creators of Scrum, puts it this way: Scrum is like
your mother-in-law, it points out all your faults.

Scrum is you mother-in-law

The Scrum Core

diagram depicts what is at the core of Scrum.

I made this diagram based on what I learned from Alistair Cockburn from his heart of agile course. I have tweaked and adapted it a little.

is all it comes down to. Do this and you are doing it right, don’t do this and
you are doing it wrong.

The Scrum Core
The Scrum Core

my opinion, if you are missing any of the 4 items at the core of Scrum, you are
not doing scrum.

you have stand-ups and sprint planning, and all the details of the framework
but you are not delivering or demoing every sprint you are not doing scrum.

you are highly efficient and your velocity has improved 10 fold in the past quarter
but you are not focusing on the highest value first you are not doing Scrum.

If you are following all the rules of the scrum guide but your testers are all offshore and programmers need to do a handover to them you are not doing scrum.

you are delivering working software every sprint and your customers are happy
and it’s all rainbows and butterflies but you are not making changes based on
your retro actions you are not doing Scrum.

make sure to focus on highest business value first, deliver (or demo) every
sprint, have a cross functional team, and inspect and adapt every sprint. The rest
are peripherals.

should get the basics right first then move to the details. Focus on the core
always while you are implementing the various scrum artefacts, roles, and
ceremonies. And make sure you evaluate everything with these principles.

Further reading: