The 5 most annoying things people get wrong about Scrum | Jesse Fewell The 5 most annoying things people get wrong about Scrum – Jesse Fewell

The 5 most annoying things people get wrong about Scrum

By March 5, 2013Blog, Uncategorized
courtesy a n i. Y.

courtesy a n i. Y.

I’ve had it.

The other week I heard the umpteenth person make some misguided, mistaken declaration about the rules of Scrum. I hear it way too often. “Scrum says this” or “Scrum says that”. There is a ton of misunderstanding out there about what Scrum is and what it isn’t, and it’s driving me crazy. Using the Scrum Guide and the ScrumAlliance’s definition of Core Scrum in the Agile Atlas as our official definitions of Scrum, let’s see if you’ve heard any of these biggest offenders:

5) “Scrum says we have to estimate with story points”. Um, no it doesn’t. The Guide and the Atlas give very specific guidelines for when to estimate Product Backlog Items. So, you may be surprised to learn Story Points are decidedly NOT included in those rules. In fact, Scrum co-founder Ken Schwaber has been an ardent promoter of Ideal Days. Which estimation technique you use DOES NOT MATTER, only that you use the technique consistently.

4) “Scrum says the product backlog may only include User Stories”. Oh, and while we’re at it, user stories are NOT mandatory.  YES, user stories are a great technique, and YES they facilitate a more robust understanding of the work that needs to be done. But the Scrum Guide does not mention them at all, and the Agile Atlas lists them only as a Generally Accepted Scrum Practice (GASP) and not a part of Core Scrum . If you have a thousand requirements formatted as “the system shall provide…”, and they consistently meet the INVEST principle, then please don’t go spending 2 months rewriting them into the “as a, I want, so that” format. Also, don’t forget infrastructure work and spikes should be well groomed Product Backlog Items, but force-fitting them into User Stories can often be clumsy. The goal of any Sprint is to produce a product increment of running, tested features; however you do that is up to you.

3) “Scrum says the Product Owner is not allowed to attend our meetings.” Okay, I see why you might misinterpret this from the Scrum Guide’s rule that “only Development Team members participate in the Daily Scrum.”  However, the Atlas asserts a clarifying counterpoint that “only the Scrum Team members, including ScrumMaster and Product Owner, speak during this meeting.” Specifically, it is totally possible (and even desirable) for a ScrumMaster to facilitate a positive dynamic for the meeting, without actively participating in the conversation. Likewise, as a full and equal member of the whole Scrum Team, the Product Owner has every vested interest to observe the meeting, and offer some assistance to the Dev Team Members. The key here is that we protect the self-organizing dynamic of both the internal Development Team and the broader Scrum Team.

2) “Scrum says the Product Owner must be the product business sponsor”. No, Scrum doesn’t say that. Scrum is a team-level method. The Atlas says “The Product Owner is typically the individual [on the Scrum team] closest to the ‘business side’ of the project.” Each and every Scrum team has a team-level business point of contact “who is expected to do the best possible job of satisfying all the stakeholders.” That includes the product business sponsor, the executives, and even the Product Owners of the product’s other Scrum Teams. Often, the business sponsor doesn’t have enough people to staff a team-facing Product Owner for each and every Scrum team. So, we will recruit a Development Team (a business analyst or a tester, maybe) to step up and play the part of the team-level Product Owner. Then, that person will be the one “responsible for maximizing the value the product and the work of [that specific] Development Team.”

…and coming up at Number 1…

1) “Scrum means we don’t do any up front planning”. Really? Where does is say that? If you believe that, then let me ask you this: where does the Product Backlog come from? Can you start Sprint 1 without one? You have to do some minimal amount of Product planning BEFORE you begin formal Sprint Planning. In fact, both standards require Grooming or Refinement as a means “to prepare for the upcoming Sprints” [fromt the Atlas]. Then, after the first Sprint begins, the Guide explains that Grooming continues “as a part-time activity during a Sprint between the Product Owner and the Development Team…[consuming] no more than 10% of the capacity of the Development Team.”  Furthermore, the larger the product initiative, the more Grooming and Refinement will be needed in advance. Just don’t go planning all the details of all the features for the whole product.

What about you? Have you heard these in your workplace? What other have you heard that are annoying?