Pure Scrum

I just finished two days of official Scrum training, which was surprisingly different than the Scrum I have learned and practiced for the past 10 years. Here are some notes from the class.

Posted on

Scrum is a simple approach to software development based on Agile. I have been using some form of Scrum, at least personally, since the mid-2000’s when I learned about Extreme Programming, then Test Driven Development, Agile, Gherkin, Behavior Driven Development, actual Scrum, and the Scaled Agile Framework. It’s safe to say that I have picked up a lot of non-Scrum practices along the way, and while they are not necessarily bad, they aren’t necessarily Scrum. So I thought I’d write a bit about those little differences.

Daily Scrum

Scrum calls Standups Daily Scrum. The mixup probably came from Extreme Programming which has a daily standup meeting. The typical Standup is focused on what each individual did yesterday, what they will do today, and whether anything is blocking them from getting their work done. But that isn’t the only approach.

A better approach might be to look at the Sprint Backlog to see how things are coming along, discussing the items as needed. I like this because it puts the emphasis on the product and the team, not the individual.

Product Backlog Items

User Stories in Extreme Programming are called Product Backlog Items in Scrum, and Scrum doesn’t care how you write them as long as they are defined with sufficient detail.

That means that my beloved As a <role> I can <capability>, so that <receive benefit> format isn’t necessary, and neither are Scenarios as defined in BDD and enhanced with Cucumber’s Given... Then... When... syntax. Both of which I lurve.


Ceremonies are just Events in Scrum. By the way, there are no gaps between Sprints which means that all Events take place during a Sprint.

  • Sprints can last up to a month
  • Daily Scrum meetings are 15 minutes tops
  • Sprint Planning can last up to eight hours
  • Sprint Review up to four hours
  • Sprint Retrospectives are up to three hours

That’s up to about 20 hours of meetings during a three week sprint. I can tell you from experience that, while it seems like a lot, it can really pay off.

Sprint Review

The Sprint Review isn’t supposed to be just a demo. It is supposed to be a collaborative working session with everyone on the team, including the stakeholders, to provide feedback on the product. The Product Backlog should be updated as a result of any feedback gathered during the session.

It is also important that only releasable code is shown during the review. If it isn’t truly done, then it can’t be released, and therefore should not be part of the review.


There are three main roles in a Scrum team: Development Team, Product Owner, and Scrum Master. Scrum doesn’t prohibit the Develepment Team from interacting with the Product Owner, Stakeholders, or Customers (end-users), in fact, it encourages that kind of thing.

Interestingly, Scrum seems to reduce the responsibilities of the Scrum Master to simply to helping the team understand Scrum and removing any impediments to the process. The Scrum Master does not “drive” the team by handing out tasks or telling people what to do.

Scrum allows Scrum Masters and Product Owners to be on the Development Team, but it recommends against doing so because of conflicts of interest and high workloads.

Development Team

The Development Team consists of everyone who is doing the work of creating the product during a sprint. This includes but is not limited to, programmers, designers, marketing, writers, and researchers.

Scrum stresses that the Development Team is completely self-organizing— only they can decide how to turn the backlog into functionality. It is also worth noting that the Development Team recognizes no titles or sub teams such as Lead Developer, Architect, or testing team. The whole team pitches in to complete the increment regardless of individual specialization.

There are probably many other modifications to Scrum that I have picked up over the years, but these are the main ones that came up during training. I don’t think that these modifications are necessarily wrong—honestly I think many of them are awesome, but I have a natural bias toward systems and processes—they just aren’t Scrum, or “pure” Scrum.