Wednesday, October 14, 2009

Some Scrum Fallacies

I been looking into some Scrum concepts that we take from learned but are wrong from a conceptual level, I compiled a list that you can read see below.
  • The PO (Product Owner) prioritize team's activities. This is false. The PO main responsibilities are to provide feedback, answers questions about items in the current Sprint, and work with the stakeholders. The Team is in charge or prioritizing its activities.
  • The Sprint has to last a calendar month. False again. The Sprint can last a month or even less, it can also be extended under special circumstances and with PO's approval. However, the Sprint shouldn't be so long that it doesn't adjust to business events.
  • It is necessary to have a vision and product backlog to start and sprint. False. There are important things that you'd like to have before starting an Sprint, things like a release plan, budget, executive sponsorship, technical leadership, team space and team rules, backlog, etc. Nonetheless, those things are not essential for starting and Sprint, remember, Scrum is about adaptation and not fully detailed planning.
  • All the Sprint Backlog must be defined up to 100% in Sprint Planning meeting. False. The team just need to identify all the necessary tasks to complete the selected Product Backlog items that will be tackled during the Sprint.
  • The SM (Master Scrum) is responsible for removing team members that are not performing well or disturbing other team member's work. False. In Scrum we have self organizing teams that can decide to remove team members by themselves, the SM may provide advice but the final decision has to be team's call.
  • Burndown charts show how much effort has gone into the Sprint. False. Burndown chart essentially shows estimated work remaining for each day of the Sprint.
  • During the Sprint, identified tasks are added as soon as the PO approves their inclusion. False. Tasks needs to be added by the team as soon as their are identified, no need to wait for approval, agility and proactivity is crucial.
  • The team is responsible for selecting the PO. False. Even thought we have self organizing teams and that the SM role can be rotated, the PO is appointed and can't be removed, at least not for the team.
  • The SM has to attend to the Daily Scrum. False. The Daily Scrum is a inspect and adapt meeting for the team that does actual work in the project, so no need for the SM or PO to attend unless they are invited by the team. The SM however should collaborate setting the logistic for the meetings: reserving a conference room, providing phones, sending invitations, etc.
  • The Sprint Backlog will be the output of the Sprint Planning Meeting that will set the direction for the next Sprint. False. The target and direction for the team will be provided by the Sprint Goal.
  • The PO has to ship each Sprint increment when it'll be free of defects. False. The Po has to ship increments whenever he feels that this make sense, of course that they don't have to have defects but this more like an enabler and not the ultimate motivator for shipping.
  • A Product Backlog item is considered completed when all its tasks are completed. False. A Product Backlog is actually completed when it meets all negotiated acceptance criteria.
  • User stories are included in the Sprint Backlog. False. User stories are decomposed in tasks during the Sprint Planning Meeting and then they go into the Sprint Backlog.
  • The SM has to act as a go-between the PO and the team. False. This is the least communication technique that the SM could use, more effective ones are: monitor communication between the team and the PO, teach the team to talk business languages , teach the PO technologies involved in the product.
  • The SM or the PO are in charge of updating the Sprint Backlog during the Sprint. False. The empowered team takes the decision of updating the Sprint Backlog to reflect their decisions and tasks progress.
  • Teams make adjustments to their engineering practices only after consensus was reached in a Sprint Retrospective meeting. False. Teams are adaptive in nature and need to take initiative and adapt their practices whenever needed.
  • The SM is an engineering position. False. The SM is a management position.
  • The product has to be shipped at the end of each sprint. False. The product needs to be shipped when the PO decides to ship it and taking into account a release cycle that includes marketing, finantial, legal and other implications.


  1. I am wondering where these "fallacies" come from as I have never heard anyone "train" these ideas nor operate based on them. Once in a while, someone may ask about something related to a few of these, but I've never come upon a team or organization who thinks these "fallacies" are correct.

    I'd call these crazy made up ideas from who knows where!

  2. Great post Juan, however some of the points you mention are more of a case of "well, it depends" not-so-much true or false.

    The PO (Product Owner) prioritize team's activities: the PO DOES prioritize the teams activities indirectly. If the team pulls in 5 stories into the iteration, they should be working in priority order. The team shouldn't decide to work on tasks from the lowest priority.

    It is necessary to have a vision and product backlog to start and sprint: without a backlog, where is your release plan coming from? If you're talking about "Iteration 0" as prep time you still would need budget approval in the real world plus a vision and/or reason for doing the project in the first place.

    A Product Backlog item is considered completed when all its tasks are completed: this is a also a "well, it depends" and there is a difference between completed stories and accepted stories in some circumstances. If you're automating all your acceptance tests, great but in the real world that is pretty rare.

    Great article though, I just think many of the statements are too complex depending on context for true/false to be sufficient.

  3. Scott,

    Believe or not there teams that believe in these fallacies, maybe because they were not properly trained or somehow down the path they got confused and start to misuse concepts.

    Curiously enough if you convert this fallacies in questions and ask them to Scrum teams, you'd find in many cases that they responded true instead of false. I know this because I tried it.



  4. Jason,

    I like the "well, it depends", and it's true, in many situations you can not put all things in a black and white perspective, there's always a lot of gray in between.

    Thanks for you comments,