Opening Remarks
Speed = Distance/Time
The simple definition of speed is how fast an object is moving.
In a team’s reference, speed is simply how fast they can produce the output towards reaching the common goals/objectives. Today, we are looking at an example where the team tries to find their speed to accomplish a user story in story points.
The scenario, That is, a session in progress:
It was a backlog refinement ceremony in progress. The user story in the discussion was well written. The efficient Product Owner (PO) shared the information on what's needed and expected out of a story. The team discussed and clarified their queries. The PO and the team furnished the story with clear acceptance criteria.
It was the right time for sizing the story. The team used digital planning poker to estimate the size of the story using the Fibonacci sequence.
Scrum Master (SM): Team, do we have questions on the story before we go for the sizing?
Team: No questions. We have enough information to size the story.
SM: Ok then. Get ready. Cast your votes. One! Two!! Three!!! Go.
The team of seven voted with the following numbers for the story: 8, 5, 1, 2, 3, 3, 2.
Why are we wasting time?
SM: That is a pretty wide range of votes. Let's hear the thoughts from those who voted high. Why do these two members think the story is 8 or 6 in size?
Associate 1: I’m new. Still ramping up. My core strength is the backend. This is the front-end application work. And, I… mmm… well… I don’t know! I don’t know!!
Associate 2: I had some thoughts. But if the team thinks that it's a small effort, I am ok to bring my number down.
SM: You voted 5. Share your thoughts behind it.
Associate 2: Well, Yeh! I thought it is a critical fix since we are touching the core functionality of the application. And, I considered efforts for creating the test data in a lower environment. Do we need Team-X’s help for data?
SM: OK. Let's hear from those who sized it low.
Associate 3: I have known this system for years. This should be a quick fix. I have a clear idea of where we need to apply the changes. Testing should be straightforward. I can help the tester.
Associate 4: Yup! Associate-3 can easily fix it. And that's why I voted 2. He is a hero.
SM: What about others?
Associate 5: Not sure. Three is my guesstimate. I was eager to hear from others. Not sure if I need any special access to work.
Associate 6: Associate-3 is a Rockstar. He got everything we need, my friend. He can take care of it.
Associate 7: I am a tester, can test this story. No big efforts. One or two should be the size. We have the test data too. No dependency.
PO: If Associate-3 and 7 can work, we should consider only their inputs and move on. Why are we wasting time in this discussion?
In this scenario, only one or two team members had the necessary skills and knowledge to develop the story, who voted one and two. The vote eight was from the newest team member.
What did they size the story?
You are only as fast as your slowest team member
PO: … … Why are we wasting time in this discussion?
SM: We don't know who will be working on the story when it makes it to an active sprint. We are trying to get a unanimous voice on story sizing.
PO: Still, since we know the efforts are low, size one or two should be taken into consideration, and we can quickly move on to another story to refine.
SM: Let the team figure out what is their size for the story.
Associate 3: It's not more than 2.
Associate 2: How much learning is involved if I join you for the development part?
Associate 1: I would like to join hands for learning. I want to understand the application and details of this enhancement.
SM: Associate-1 may not have the required access to the system. We must consider listing the requisites. I can certainly help following up with the helpdesk.
Associate 7: The application is not complex, but surely needs a couple of hours of overview session. But that would certainly help for a few more stories we are expecting in future sprints.
Associate 3: I second that. But do we want to spend the time on the team's training right away?
SM: Maybe. Let's assume that onboarding efforts and size the story.
Associate 6: Alrighty!!! Sounds like we know the size better now, my friend.
PO: Are we not over-engineering?
SM: Well, you are only as fast as your slowest team member.
[A few thumbs up in the room]
SM: Let's go for another round of story-sizing. Get set… One! Two!! Three!!! And Go.
[This time the team voted: 5, 3, 2, 3, 3, 3, 2.]
Associate 3: I am good at raising the size to 3. I agree that the new guys need little extra effort. It should not be more than a couple of hours though.
Associate 1: I am good with 3. I… Mmm… I mean it. Let’s give it a shot.
Associate 6: 3 it is. All aboard!
[Thumbs up in the room]
So, 3 is the size!
Key points
Why did the Scrum Master emphasize on a unanimous thought for story size? Why not only the opinion of the most knowledgeable person in the team is considered to size the story?
We did that for several reasons:
The team is responsible for the size of the story, not one associate or a silo in the team.
Tough to be sure who will work on the stories.
The most knowledgeable person may work on it. Or may operate as a support system.
The learning efforts to bring everyone on the same level of knowledge should be considered.
Understand the factors outside of their role.
The story should create a suitable workload.
Understand the balance of expertise (technical or functional) in the team needed by the story.
The Fibonacci sequence (or the modified Fibonacci sequence) is used to denote the relative size, that includes:
The amount of work to do (including learning and exploration).
The complexity of the work.
Any risk or uncertainty in doing the work.
Knowing the speed of the team is a helpful tool for every associate on the team. This helps in committing the work. And as a team, you are only as fast as your slowest team member.
