Ten things not in Scrum
Last year I did a public speaking session on Scrum, and one of the questions that arose, again and again, was, “How many times this is mentioned in Scrum Guide[1]?” This question gives me an idea to compile things mistakenly believe to be a part of Scrum. Here is a list of few items I can think of on the top of my head.
Jira
How many times did you come across a team that claims to be an Agile or Scrum because they are using Jira? Or to be more accurate, Jira, and daily standup. Although lots of teams are using Jira, it is just a Software tool, and it is not mandatory to use it to call someone Scrum Team; neither is it mentioned anywhere in the Scrum Guide. One can do Scrum without it, or even without any tool at all, even Microsoft Excel used in one of my experiences.
User Story
“All the stories must be written in an Agile format.” We got an email from our new lead that is something similar to this. I read this and have two immediate questions. What is the “Agile format”? Has anyone ever heard this term before? Second, do I have to write all the Product Backlog Items in the form of user stories? The term “User Story” is popularized by Ken Beck in his famous book “Extreme Programming Explained” [2]. Again the same question, how many times the user story mentioned in the Scrum Guide? And the answer is zero. Scrum Guides uses the term “Product Backlog Item,” also known as PBI, which is not limited to only user stories. I do agree that writing user stories are great practice, but do not assume that we can’t do use any other format in our Product or Sprint Backlog.
Story Point
What is the story point? There is a high possibility that you will get different answers from different persons. Here is a definition of a story point from Mike Cohn, “Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work”[3]. Some teams can correlate story points with the number of hours, which is another topic for discussion. Let’s take a look at the Scrum Guide what is there, at least I couldn’t find anything like story point when last time I read it. The closest I can find in Scrum Guide is “Product Backlog items have the attributes of a description, order, estimate, and value”[1]. One can do the estimation in any way that makes sense and does not have to use “story point” for an estimate.
Velocity
How common is this to get instruction from the leadership about how to improve the team velocity? My first response is, what does “velocity” mean to you if you are a customer? If a story point is not in the part of a Scrum Guide, then how can we calculate the “velocity”? How do teams measure performance over time is left to the Scrum team to decide. Bouns points question, what is the correlation between velocity and technical debt?
Scrum Board
“What is the difference between Kanban board and Scrum board?” I got this question in one of the chats, and my reaction was, “What is Scrum Board?”. Yes, most of the teams are using some board for visualization of the current state of the Sprint, and it is available in almost all Software tools, but these are just a Kanban board without any WIP limit and particular swim lane. There is no such thing as Scrum Board defined in Scrum Guide. Teams are free to use whatever tool, or in other words, information radiators, they prefer, not restricted to the only variation of Kanban board.
Backlog
Let me share one conversation I had during one of the meetings. “I put it in Backlog.”, “Which backlog?” “My backlog.” Confused, I never heard the term “my backlog” before, so to be more specific, I asked “Product Backlog or Sprint Backlog,” the response is the same “My backlog.”
How many times during the conversation, you came across the word “backlog” and had to infer what does it mean, and imagine the confusion if they are not on the same page. There is no such thing as “Backlog” in Scrum. Scrum Guide only defines “Product Backlog” and “Sprint Backlog.” Whenever the word “Backlog comes in the Scrum Guide, it always prefixed by either Product or Sprint.
Team
Like, Backlog, “Team” is not defined in the Scrum Guide and creates confusion, during the conversation. Scrum Guide describes only “Scrum Team” and “Development Team.” At least I am confused and have to ask what does it mean when some said only “team” in front of me. Similar to the Product Backlog/Sprint Backlog, some can easily infer different meanings with the word “team” if not using in proper context and setting.
I experienced an unusual situation in one organization, there are many development teams and many product owners, and the relationship between development teams and product owners is many to many. In other words, one product owner works with many development teams, that is not a problem so far, but one development team works with many product owners too. Yes, they violate one of the basic rules of Scrum that “The Product Owner is one person, not a committee.”[1]. Besides, what is the Scrum Team here?
Assign
“How was the Sprint planning?” I asked the question to one of the Scrum Master in one of the many teams. “Yea it went very well, we first try to find out if anyone goes on vacation to find out our capacity, then I assigned the appropriate user stories and story point to everyone in the team to maintain our velocity” the response I got.
Did anyone notice any problem? Even if we ignore “Story Point,” “User Story,” “Team,” and “Velocity,” the biggest problem here is assigned the work. Scrum is like a team sport where everyone working towards a common goal, not a push-based mechanism.
Definition of Ready
It’s a “Backlog refinement” time, and everyone has a copy of “Definition of Ready” in his hand, and discussion is going around the checklist of “Definition of Ready,” sounds familiar. Although “Definition of Done” is a part of Scrum, but “Definition of Ready is not.” The potential danger of using this practice is used as a phase-gate, as Mike Cohn describes in his article[4]. Teams may stop moving the stuff from Product Backlog to Sprint Backlog during the Sprint planning, claiming that not all the items of “Definition of Ready” are not checked make it like a waterfall or phase gate. It should be used as a guideline for the development team to better understand the work.
Release Planning
“Release planning is longer-term planning that enables us to answer questions like ‘When will we be done?’ or ‘Which feature can I get by the end of the year?’ or ‘How much will this cost?”[5]. Although it is beneficial, and SAFe PI planning is also based on it, but it may be surprising for a few, that “Release Planning” is not defined in Scrum Guide.
Reference
- Scrum Guide https://www.scrumguides.org/scrum-guide.html
- Extreme Programming Explained by Kent Beck
- What are Story Points by Mike Cohn https://www.mountaingoatsoftware.com/blog/what-are-story-points
- The Dangers of a Definition of Ready by Mike Cohn https://www.mountaingoatsoftware.com/blog/the-dangers-of-a-definition-of-ready
- Essential Scrum by Kenneth S. Rubin
