Handling Uncertainty is the Key to Scrum Installation

Photo by rawpixel on Unsplash

This article describes my experience to install Scrum in a new development team. I learned that the key point was to understand how we handle the uncertainty.

Background

Recently, I was in charge of building one development team. My team was lucky enough to install Scrum successfully.

We had a Scrum Master who is enthusiastic to learn how Scrum works. He took Scrum Master training before the project. He successfully achieved his responsibility throughout the project. I, as development lead, had an experience in both of successful and unsuccessful Scrum team before. So I had a knowledge of how we can make a success with Scrum. We had team members who did not have any experience but enthusiastic to learn Scrum.

Why I said lucky enough? In my department, several other teams were also trying to install Scrum. However, almost all the other team failed. What was the difference? We had members to support Scrum, other teams do not. That’s it. The other teams have less number of people who are experienced in Scrum, or enthusiastic in Scrum. The management was serious to install Scrum. But teams did not realize the value of Scrum and eventually stopped it.

Typical Failures

I could find several failures in Scrum installation process as I talk with the other team members.

Fail to Understand Relative Estimation

When I install Scrum, I usually get questions or words like the following:

Let’s say one story point corresponds to one man-day. Then that story will be x point.

Why we use such a vague numbers instead of concrete estimation?

How the vague numbers help project management?

Story point is a methodology to make a relative estimation. Relative estimation provides us quicker and also accurate result. Look at the example the below. Absolute estimation requires more effort. We have to identify all the effort including design, review, implementation, and QA. This requires a lot of clarification before the estimation. On the other hand, the relative estimate is really quick. We estimate like “Story B looks like twice complicated than Story A”.

Relative estimation is instinct based estimation. Some of you might feel like this is an inaccurate approach. But let’s think about how accurate absolute estimation is. Most of the software development did not work as initially planned. The design might take extra Y days. We got an unexpected bug on QA which take Z days. In the end, your plan did not work as planned in most cases.

I think relative estimation is more accurate because we can keep updating the estimation result by the achievement. If we finish Story A in 5 days, we can estimate Story B will be finished in 10 days. If we finish Story A in 10 days, B can be estimated as 20 days. We can keep updating the estimation anytime. Typically in Scrum, we will keep track of velocity at the end of each sprint. Therefore, we can keep updating the estimation every sprint naturally.

There are also several academic research result which shows people are better in relative estimate than an absolute estimate.

Avoid Running with Uncertainty

At the beginning of the project, I got the question like the below from a member:

How we can make estimate even though we don’t have enough clearly?

The power of story point is to let us estimate with uncertainty. Since story points are more instinct base estimation, we can provide rough estimation with less clarity.

In the real world project, it is quite rare that everything is clear at the beginning. Typically the clarity increases as project proceeds like the below.

When the team is working on story A, story A has the best clarity. Maybe the team is working on a basic database schema. As story A has no dependencies to the other stories, everything is clear. Story E has least clarity as we do not know what database is used, how the table schema looks like, and how the new application code looks like yet.

We can make a rough estimation using story points at the beginning. As we complete some of the stories, later stories have more clarity. We know what database technologies to be used, how the table looks like, how the application structure is. Your product owner might find more concrete requirements as well while the team is working hard to implement the product. Then we can keep updating the estimation.

The following is an example of a burndown chart of story points throughout the project. I made this example based on my experience in the latest project. In the beginning, everything is estimated roughly with conservative assumption. We can see the drastic story point drop at Sprint 4. Please note that this is not just because of sprint achievement. We get more clarity as we worked on several sprints in the beginning. Therefore, we can make a more realistic estimation. We drop some of the non-scope items as well as we get more clarity on our product scope.

As you can see the above, we can start planning with uncertainty at the beginning. We can gradually improve the estimation while getting more clarity. Scrum is designed to run with uncertainty not to clarify everything at the beginning.

Conclusion

As we see the above, Scrum is designed to run with uncertainty not clarifying everything at the beginning. This is the key part of Scrum. If the team does not understand this principle, it is quite hard to understand the value of Scrum.

When you install Scrum to your team, you have to understand this principle and keep coaching your scrum team through this principle.

Global team builder from Tokyo. Engineering manager to build international engineering organization.