Sticking with the theme Dan Neumann, Sam Falco and I came up with for AgileThought’s Agile Coaches’ Corner podcast episode. Here is the blog post exploring some of the Scrum Cling-Ons that seem to be embedded with Scrum but are not defined within the Scrum Guide. While Dan and I had a good conversation, we did miss not having Sam in on the conversation for this one.
We were not able to touch on all of the various things that appear to be attached to Scrum even though Scrum makes no mention of them. So this is an attempt to put some of these Scrum Cling-Ons into writing.
https://agilecoachescorner.libsyn.com/scrum-cling-ons-and-culture-shift-with-chris-pipito
Story Points
Story Points may be the cause of most pain with teams using any “agile” method. But it appears Story Points have been equated as a solid part of Scrum as if it is prescribed in the Scrum Guide. Well, it is not. The phrase “Story Point” appears exactly 0 times in the Scrum Guide. Story points lead to multiple different dysfunctions within teams and the organization. At the team level, it is difficult to understand what a single “point” actually means. This leads to even less accurate estimation (if there ever was accurate estimation in the first place). In the organization, Story Points are used in ways that cause far more damage. Teams are compared, tracked, and pressured based on the number of Story Points they predict they will complete vs. their “actuals.” My stance on Story Points is very clear: on multiple posts I have written Killing Agility: One Estimate at a Time, Blind to Agility, Story Points… Why? and Story Points Dysfunction.
Just in case people think I just hate estimates for some arbitrary reason, very many agile thought leaders share my same views. I reference a fair amount of these prominent community leaders in Killing Agility: One Estimate at a Time.
Again, I always say nothing stops you from using Story Points or any other form of estimation. But, I would question what real value it is providing if you choose to do so.
Planning Poker
Planning Poker is a method that provides the Story Points. So naturally I put Planning Poker in the same box of dysfunction as Story Points. But it is also not mentioned in the Scrum Guide at all. No specific method of estimation is mentioned in the Scrum Guide. The words “estimate,” “estimates” or “estimation” do not even appear in the Scrum Guide at all. And I have heard, and even had it make logical sense to me, to use Planning Poker as a means of collaboration. This logic states that if a member of the Scrum Team thinks something is a 1 and another member thinks it is a 13, or some other significant spacing in a form of Fibonacci sequencing, clearly we do not have a shared understanding of what the Story is stating needs to be done.
My argument to this is that the Story itself is probably too big to begin with. Instead of focusing on then having the conversation about why this person’s Story Point estimate is so different from the other person’s Story Point estimate and having them explain themselves to the team so that the team can play Planning Poker again. How about just focus on creating what is referred to as “right-sized” stories. And this would happen before any form of estimation would be asked for. I like Neil Killicks idea of splitting, I prefer the term narrowing, a Story to a single acceptance test. And if you are doing this, more often then not these right-sized Stories will take roughly a day to get all the way to done. So why estimate? Just count Stories!
If you are forced to estimate, for example the organizational leadership or management demands you provide estimates, well you have larger problems than Story Points.
If you however enjoy Planning Poker as a technique, I recommend the lunar logic deck. There are only 3 cards. 1,TFB,NFC.
At the same time I say this, I also have the ability to believe that to each their own and do as you wish when it comes to using Planning Poker and Story Points. Live and be well… But know that you are adding waste to your process.
But I know what argument is coming. “Scrum doesn’t say to use Stories.” Well for that, we have the next section…
Stories
Stories originate from Kent Beck and Extreme Programming. The count of times the word “Story” or phrase “User Stories” appears in the Scrum Guide again, is exactly zero. Scrum refers to everything as “Product Backlog Items”. Now this does not mean you aren’t permitted to use Stories to define the work item, but just for the sake of stating fact, Stories are not called out in the Scrum Guide as a must use.
Are Stories in my opinion the best way to create software? Absolutely. Considering we build software for people that have a story about what they do, problems they have, and things they need to accomplish. I would always want to use Stories to portray what our customers do with the software we build.
Mistakes happen with the misuse of Stories whether using Scrum or not. But I have yet to work with any team that initially didn’t think that Stories must be used for everything they do because they are using the Scrum Framework.
And that nicely leads into the next section.. The dreaded “User Story Format”…
User Story Format
I actually have to give a great amount of credit on this one to Mike Cohn. So the format I am referring too was originally created by Rachel Davies and is known as the Connextra Format.
As a <type of user>, I want <some goal>, so that <some reason>.
But Mike Cohn took that ball and ran with it, making that format so popular that it was viewed as “the way to write User Stories”.
I understand and have even used this Story writing technique quite a few times. But as it relates to Scrum, there is no relation specifically to using it.
Furthermore, the misuse of forcing this format causes pain. I think people new to Story creation could use this format to some benefit, but I also think they may be better off just writing down the who, what , and why of the thing being built.
Now if you are doing something that has no impact to the user at all, then I would certainly not use this format at all.
The important thing to remember though if you are going to use Stories, and I can’t emphasize this enough, is it is not how you write a User Story, it is how you use a User Story that matters.
Create the User Story Card with the basic statement of who, what, and why, in any format that helps you.
Have the Conversation about the User Story with the user and the team that will be building the solution.
Confirm that we all have a shared understanding of what to build and how it will work.
The format of how that is written, in my opinion, is secondary to the way the Story is used.
Epics and Features
Scrum also makes no mentions of Epics or Features. Epics are often described as just big User Stories.
Mike Cohn defined an Epic as a large user story.
“There’s no magic threshold at which we all a particular story an epic.”
Jira uses Epics in a hierarchical way that I think is misused by users of Jira. Epic>Story>sub-task. And how I have seen people use this is to take some implementation task, break it into many “Stories”, then break those “Stories” out with “sub-tasks” of work. I understand why people do this, but the work broken out is often not deliverable to a user on its own. So its not a Story.
Features follow much of the same treatment as Epics, but from my experience, Features are mostly used within the SAFe framework. I can’t even begin to discuss my thoughts on SAFe at the moment. Too much brain drain. But I will summarize to one quick statement.
“There is not much agility in any framework that requires 320 pages to define.”
Velocity
Yet another thing that is used but appears exactly zero times in the Scrum Guide. I am actually wrote another post on “Velocity: The Scourge of Teams”.
Velocity with Scrum is the average number of Product Backlog Items that are turned into Increments during the Sprint. This metric I have seen used for good when the team wants to track it, the team uses it, and when Velocity doesn’t escape to management.
But I think Velocity is a very problematic metric that we should just do away with as it has far too many negatives for the good it provides.
- Comparing teams velocity as a means to increase one teams productivity
- Increasing Velocity demands by the “more! faster!” mindset
- Using Velocity as a measurement to gauge performance
- Loss of real trust and transparency when used for performance reviews as the metric is now gamed
“You tell me which metrics a team will be judged on, and I will tell you which metrics will be manipulated.”
Sprint Types (Design Sprints, Implementation Sprints)
Scrum does not describe a working process of Sprints by phase gate. Within the Scrum Guide is the statement:
“The entire Scrum Team is accountable for creating a valuable, useful increment every Sprint.”
Now I know people are free to determine what is a valuable, useful increment. I have done this myself as well, and even wrote about it in Scrum Guide 2020: The Scrum Team.
To me, and most everyone else I have had conversations with, a valuable, useful Increment is quality working tested software that our customer can use to achieve some objective or solve some problem they have.
If you have a Design Sprint, that may give the customer an idea of what will be built, but it does not provide them with a workable useful Increment.
Implementation Sprints like Development Sprints, Testing Sprints, Hardening Sprints, and Integration Sprints do not provide the customer with a valuable, useful increment of software.
Project and Portfolio Managers
This goes back to the roles of Scrum. Scrum defines three roles on a Scrum Team:
- One Scrum Master
- One Product Owner
- Developers
There are no Project Managers or Portfolio Managers mentioned in the Scrum Guide. This is not to say that some of the work that is usually done by these people are not valuable or needed. Scrum does state explicitly:
“The Scrum Team is responsible for all-product related activities form stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.”
This is supporting the fact that the members of the team need to have all of the skills to create value each Sprint but does not support the idea of sub-teams within the team. Yes things that are not strictly code still need to happen, and in some cases take significant effort from the team depending on the variables of what makes up the product they work on. The team needs to account for this work, organize who will handle it and when it needs to be done.
Closing
I would like to thank Sam Falco and Dan Neumann for the opportunity to be a guest on the Agile Coaches’ Corner Podcast. And another thank you to Dan Neumann for taking time to have that conversation with me as well as curating this post.
Chris Pipito 