Where do we religiously follow Scrum

Where do we religiously follow Scrum

First of all the title is wrong!

You either do or do not follow Scrum religiously.

After a 2 year experience in Scrum, our organization has inevitably slipped from Scrum many times and most of the times we regret it and switch back to discipline. There are some things though that we never compromise:

Steady Cadence

We started Scrum with one week Sprints and when the teams matured we switched to 2 week sprints. So in 2 years most of the teams have only changed their Cadence once. Changing the Cadence is a decision that came organically from the teams not necessarily in the same period.

But having a standard day and time when the events take place is non negotiable, even when stress and pressures comes from above.

Scrum Events

Every sprint ends with a Sprint Review followed by a Sprint Retrospective and starts with a Sprint Planning Meeting.

Sometimes, many team members think its better if we skipped this sprint’s retrospective. In this case I choose to make the meeting much shorter and ensure that we get out of it with at least one action item that most of the team agrees is important to deliver.

Daily Scrums (standup meetings) take place on the same time and place every day and never last more than 15 minutes. When valuable conversations arise, we arrange a meeting right after the stand up which most of the times does not need to include the whole team. When someone doesn’t appear in stand up, they have to send an email to the team answering the Daily Scrum’s 3 questions.

Well I’m pretty confident that breaking the above rules is a bad practice for any team. This is a lesson that you usually learn the hard way. Getting things back in place can be pretty challenging. The best way is through a Retrospective when as a team we realize that sticking to the rules is good for us!

Definition of Done

Well, that was quite tricky and we only got it right recently. We used to have a thorough definition of done that we were regularly enriching to increase quality. We ended up not paying attention to it.

Currently we have a definition of done with only 3 items (Code Review, Deployment – on QA or Production where applicable – and  a presentable resolution for each PBI for Sprint Review). When people tend to move the sticky note of the PBI (Product Backlog Item) on our physical Scrum Board from “In Progress” to “Done”, always someone will ask if this complies with the definition of done.

Product Backlog

The team only works on items that exist in the Product Backlog. Our Product Owner ensures that the Backlog is ordered according to priority and we regularly do Backlog Refinement meetings for scoring upcoming PBIs, identifying dependencies and preparing the team of changes in the prioritization.

A PBI can only be committed by the team if the scope is clear and the acceptance criteria well defined.

Collective Ownership

We pay great attention to the Bus Factor. Even when only one developer works on something alone, he will still need to code review with at least one other developer. To ensure collective ownership, when a similar work appears, another developer will do it even if they don’t have the expertise.


We embrace change. We are not afraid to read another team’s code and try to do our best to make their life easier when we have a request from them.


I hope to hear from you in the comments. What do you do? and now that I am thinking about it, my next blog post will be about where do we consciously slip from Scrum.

Dimitris Baltas

Dimitris is a Scrum Master and Agile Coach in the Software Development Department of tripsta Online Travel Agency (brands: airtickets, travelplanet24)

He is an active advocate of Scrum, a founding member of agilegreece.org, regular facilitator on Agile Greece Meetups and one of the organizers of the first Agile Greece Summit (September 2015). He is also a co-creator of the Rabbit Game, a game created to introduce Scrum by playing.