In every organization and in every team, I run into one or two customs that people tell me are part of "Scrum by the book", that aren’t actually in the book.

Who cares about the Scrum Guide?

I’ve been in Scrum teams as Developer, Scrum Master and Product Owner, for various organizations for 10 years, and I’ve worked with XP for 5 years before that. The book I’m referring to in this case is the Scrum Guide Of course there are plenty of great ideas that help you become agile, or outside of that simply help you build the products your customers need more effectively. However, I’ve seen that teams can go through the Shu Ha Ri of Agile and become masters by starting out with Scrum and grow from there only once they stop messing up the Shu part, which is Scrum by the book. You can read more about the idea of applying Shu Ha Ri to software development methodologies in this post by Martin Fowler

Here are 6 random things in teams that they thought was Scrum by the book, that aren’t.

1. Misconception: The sprint backlog is nothing more than a list of product backlog items

Some teams think the Sprint is simply about rushing through the product backlog items that the PO selected. Some teams think they can just cherry-pick the work from the Product Backlog as they see fit.

Neither is true.

The team may end up simply moving the top X product backlog items into their Sprint backlog every Sprint, but that is not really what Scrum says you should do.

Scrum says to look at the WHY, WHAT and HOW.

It unfortunately doesn’t do so literally which is a shame given as the WHY is the one that is left out most of the time, and as Simon Sinek explains through his Golden Circle analogy, the WHY is the most important.

Please allow me to elaborate.

WHY

During the Sprint Planning, the Product Owner provides a Sprint Goal, and in collaboration with the team looks at what product backlog items would help achieve that goal. The Sprint Goal is the WHY of the work done in the Sprint; not the WHAT or HOW.

WHAT

During the Sprint Planning, the Development Team considers the Sprint Goal, the Product Backlog, the latest product increment as delivered in the previous sprints, the team capacity, the team performance, and selects which items to take from the Product Backlog. The Development Team decides on the number of Product Backlog items they can pick up - not the Product Owner.

HOW

Once the WHY and WHAT have been decided, the Development Team looks at the HOW. This is still part of the Sprint Planning. This is more about system design and implementation. It is up to the Development Team how the work that needs to be done to convert the Product Backlog items into a working product increment. The team identifies enough work to be done that they expect (forecast) fits in the coming Sprint. Work for the first few days should be concrete enough for the team to pick up after the Sprint Planning, typically expressed as units of one day or less.

2. Misconception: You have to use story points

I’ve looked through the Scrum Guide a lot, and I advise everyone to do so regularly. Nowhere does it mention Story Points. In fact, it doesn’t even mention stories, as "user story" is also not a Scrum concept.

What it does mention:

  • A product backlog item should have an estimate.

  • Product backlog items should be reestimated, as the higher they are on the Product Backlog, the more details they will contain as a result of refinement.

  • Product backlog items higher in the Product Backlog are more likely to be picked up in a Sprint, and should be likely to fit into the time period of a Sprint.

Fibonacci

The idea of story points is that by using a Fibonacci like scale, you can express that bigger chunks on the horizon have less accurate estimates than clear units of work close to you. However, this is just a tool to help you refine work to a point where you can reasonably say that you know enough to be able to include it in a Sprint Planning. The Development Team then uses the Sprint Planning to identify and express work in units of days or less.

Planning poker or Scrum poker

On that note: planning poker is a tool developers can use to unveil different visions on the details of the work required for a product backlog item, but once that difference has been made apparent, you can take actions required to converge those visions and refine further and return to your estimates later and revise them.

The Scrum Guide does not mention planning poker, just as it doesn’t mention story points, or even user stories.

#NoEstimates

There are also people who drop estimates entirely, and find other ways of forecasting. While this #noestimates paradigm is worth exploring as it has some merit, I should point out that the Scrum Guide does literally say that a Product Backlog item has an attribute for, among other things, an estimate. What that estimate is - gummy bears, cows, Fibonacci numbers - is up to the team to decide.

Management dodging

One of reasons why people like story points, is that it can be used to empirically measure size and performance for a team internally, without risking that managers are able to use it as a way to make promises on delivery dates or a stick to beat them because their numbers are different than other teams. I used to subscribe to this point of view, but frankly: if that’s going on in your organisation, you (or more strictly, your Scrum Master) need to deal with it instead of adopting points as a language to hide your expectations and forecasts. One of the Scrum values is Openness, and it is valuable.

One thing that was actually changed in the Scrum Guide some years ago to indicate who’s responsible for making promises, is that these days, it uses the word forecast instead of commitment when talking about the Sprint Backlog.

3. Misconception: Developers cannot change the Sprint Backlog during the Sprint.

There are Developers and Product Owners, and even Scrum Masters, who say that the Sprint Backlog cannot be changed during the Sprint, or that it can only be changed by the Product Owner.

Neither is true.

The Development Team can express more work in the Sprint Backlog as long as it helps them build a product increment that helps deliver the product backlog items and achieve the Sprint Goal.

The Scrum Guide says a lot about this:

  • "The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint."

  • "As new work is required, the Development Team adds it to the Sprint Backlog"

  • "When elements of the plan are deemed unnecessary, they are removed"

  • "Only the Development Team can change its Sprint Backlog during a Sprint. [..] and it belongs solely to the Development Team."

  • "During the Sprint: No changes are made that would endanger the Sprint Goal"

  • "Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned."

Much of the confusion around what work developers do in the Sprint stems from the fact that it is the Sprint Goal that is the leading WHY that allow developers the flexibility to implement the Product Backlog items in the way they see fit. If there’s no Sprint Goal, the WHY disappears and developers are left only with the WHAT, which is more restrictive.

Once the Sprint has started, the Product Owner plays a part in the Sprint Backlog in only 2 ways:

  • They can cancel the Sprint if the Sprint Goal has become obsolete (it has become clear that it will not deliver enough value)

  • The scope can be renegotiated between Product Owner and Development Team.

4. Misconception: The Development Team consists of only software developers

Software delivery requires expertise of all sorts of people: backend developers, frontend developers, testers, information analysts, visual designers, UX designers, ops engineers, etc. In Scrum, if you are not the Product Owner, and you’re part of the team working on the delivery of the next product increment, then you are a Developer.

This isn’t a trivial thing, as it means Scrum by the book expects you to attend all those Scrum Events and involve yourself with all those discussions. Any time the Scrum Guide says "Development Team", that’s you.

5. Misconception: Product backlog refinement is one meeting

While on the subject of Scrum Events: there’s one meeting that many people view as a time consuming energy drain that Scrum in fact doesn’t even consider a meeting: the Product Backlog Refinement. The misconception seen the most is the idea that Product Refinement is one big meeting with the entire team, as I’ve mentioned before in my previous blog about time spent in Scrum meetings.

The word Refinement is mentioned only 4 times in the Scrum Guide, and they’re close to eachother, so I can just copy the entire section here:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
— Scrum Guide on Refinement

The Development Team typically spends a max of 10% of their time on these acts which may be one big biweekly meeting or 30 minutes a day before lunch.

6. Misconception: It’s a daily stand-up, so you should stand

The last point is perhaps a trivial one, but I’ll make it nonetheless. Many people call the daily morning meeting the daily stand-up.

It is not called a daily stand-up in Scrum; it’s called the daily Scrum.

The concept of the stand-up comes from Extreme Programming (XP). The standing part matters: "Everyone stands up in a circle to avoid long discussions." I was taught that it also promotes active participation, contrary to developers having to 'sit out' meetings.

That said: you can decide as a team that standing works for you. A good idea is a good idea, and in fact XP is full of good ideas like refactoring, test driven development, user stories written by the customers, and much more. Once you’ve mastered Scrum by the book, I recommend you give it a read to see how you can expand on your practices.

shadow-left