12 Surprising Facts about Scrum Methodology

After running programs using Scrum methodology since 2005, I thought I knew a lot about Scrum. Until I finally did a Scrum Alliance course and learned that there are many misconceptions that 99% of the world does not get right about Scrum. Here's my top 12 list of surprising Scrum facts.

1. A popular agenda for the daily scrum (aka the "standup" meeting) is to go roundtable, where each team member answers 3 questions: "What did I do yesterday? What do I plan to do today? What impediments do I have now?"  However the founders only meant this as a suggestion.  The true approach to daily scrum is for the Developers to adapt the agenda to what is most useful to them for advancing the work. It should not be about reporting status. 

2. The daily scrum should only last a few minutes. 15min per day maximum, but on average it should only be 5-10 minutes.
​
3. The backlog is force-ranked: #1 priority, #2 priority , #3 priority, etc. No two items in the backlog should be of equal priority. 

4. User stories don't need to have the format "As a [persona type], I want [certain functionality] because [reason why it is important/valuable]." In fact sometimes this produces "mad lib" style stories that are really hard to understand. Scrum just wants you to have an actual short story that answers the questions 1) who is this for? 2) what are we building? 3) why is it valuable?

5. You don't use Burn-down charts or Burn-up charts in Scrum. Burn-down Chart has not been part of scrum for over 10 years, and Burn-up chart was never part of Scrum. Of course, if these tools are helpful to the team, go for it! But teams that use these ritually because they think it's supposed to be part of the process are not actually applying Scrum. 

6. Scrum has evolved recently to be Goal-oriented. You always structure a sprint around a single valuable goal, not just lists of priority items. If an item is high-value (e.g. #2 item on the backlog) but doesn't relate to the sprint goal, then you don't take it into the sprint.

7. In the Retrospective, you don't just brainstorm a wish list of potential improvements. In the "Decide what to do" stage of the Retro, the team should select the most important impediment or opportunity that has come up so far in the meeting, and spend time developing and agreeing to a step-by-step plan for how to act on it. The Retro is not over unless you have a concrete, agreed plan. The Scrum Master may need to extend the time of the meeting! 

8. All team members are full-time working on the team and the product. Product Owner, Scrum Master, and Developers should not be working on another product at the same time!  If you have QA, cyber security, a lawyer involved, they too should be full-time dedicated to the product.

9. Scrum has evolved recently to be Goal-oriented. You always structure a sprint around 1 single valuable goal, not lists of priority items, and you only pull in backlog items that directly relate to the sprint goal. Even if a user story is the #2 highest priority item on the backlog, if it doesn't relate to the sprint goal, then you don't take it into the sprint.

10. If you get a new team member, you are supposed to throw out the old Definition of Done and re-create the rules document with that new team member involved. That way the new team member truly has ownership in the Definition of Done, and has the context of having been there when it was written. 

11. Scrum does NOT use certain words:
"Assign" - no one assigns tasks (because everyone is equal). Instead of "action item", call it a continual improvement item. Instead of requirements (use "product backlog item", "sprint backlog item"). Calling people "human resources" is definitely not allowed.

12. Scrum has a lot in common with running a co-op business, where the organization has a flat hierarchy and decisions are the result of team work (with the exception of product owner decisions about the overall product). The ultimate maturity goal of a scrum team is to be self-managed teams. Different from the traditional goal of "self-organized teams", self-managed teams would even include things like the team collectively deciding whether a team member gets a raise or a promotion.