How much have you scored this year? My parents asked this question twice a year throughout my schooling. When I scored 80%, they reminded my previous scores were better, and when I said 90%, they checked how much Sharma’s son scored. They also reassured themselves with follow up questions — are you in top 5, top 10, or topper this year?
I was well prepared to ask the same questions to my son, but school cheated me. They changed the percentile system and implemented a student grading system. I hope you must have understood my dilemma and challenges by now.
Have you had a similar past? If yes, then you will understand why I call it a generation gap issue.
I keep telling this story in my The Scrum Master training program and use it to teach senior management through coaching.
Let’s take a couple of minutes to understand these:
- What is software development effort estimation
- How we were estimating earlier
- What is story point estimation
- What are the challenges with story point
- Why it is a generation gap issue
What is an estimation in software development?
Straight from Wikipedia — In software development, effort estimation is the process of predicting the most realistic amount of effort (expressed in terms of person-hours or money) required to develop or maintain software based on incomplete, uncertain and noisy input. Effort estimates may be used as input to project plans, iteration plans, budgets, investment analyses, pricing processes, and bidding rounds.
How were we estimating earlier?
There were many ways, and some famous techniques were lines of code (used mainly for mainframe), COCOMO II, Delphi, wideband Delphi, and Function Points. Later we shifted to user case points and complexity points etc. There are few popular techniques from project management that we have used, such as analogous estimation, PERT / 3-point estimation, and Bottom estimation.
Analogous estimation is famous as ballpark and gut feel. An expert provides this based on historical data. 3-point is based on an optimistic, pessimistic, and most likely number. The bottom-up estimate gets calculated by a project team based on the volume of work, complexity, and uncertainty.
Most famous was/is called psychological estimation. We give number looking at who is asking? Will that person negotiate, hold me accountable for these numbers or any other consequences in the future.
What is story point estimation?
Story point estimate started after the industry adopted a new practice of expressing requirements in the form of a user story. User story started along with the movement of agile software development, and many people have contributed, including Alistair Cockburn, Kent Beck, Ron Jeffries, and Mike Cohn. Since this concept is part of agile software development, a collaborative approach of estimation is desirable. Kent Beck introduced a planning game concept in XP that became famous as planning poker.
The development team uses the concept of wideband Delphi (a consensus-based technique for estimating effort) to measure work but instead considering hours or days; they count in point or t-shirt size. The point-based system help teams to build consensus faster and forecast easily. It is for sizing work instead of estimating effort, where story points remain the same for everyone; solution time may vary based on individual skills and experiences.
Common challenges associated with story point
· Most importantly, how to convert points into hours. Most agile gurus say don’t change to hours, but one the most popular lean-agile framework (SAFe) has mentioned that one story point is equal one day work.
· Can we convert? Yes, you can but a better way. Please wait for my next blog on this.
· Can we change if we have given these numbers already?
· Is it size or estimate? Based on what?
If you look clearly, you will find only one issue here. Human is a complex creature of god; every process is transparent and straightforward unless you make it complicated. We read too much between the lines rather than reading lines.
What is the generation gap?
The sociological theory of a generation gap came to light in the 1960s, when the younger generation seemed to go against everything their parents had previously believed in terms of music, values, governmental and political views, and cultural tastes. But it is also the opposite. We have both kinds of people in our organization: Pre-agile and post-agile.
Post-agile have an issue in converting points to hours, and pre-agile people struggle to visualize effort in points because many of them haven’t done that. It is similar to the school grading system. I was very comfortable with the percentile system, and it was easy to convey. Also, it was easy to differentiate me from others because many are not going to get 87%. I tried to map a new grading system with a percentage like “A” means 80–90%, and “A+” means more than 90%. These schools further confused me by saying it is based not only on student performance on a particular subject-based exam, but also on speaking, presenting, and articulating that subject.
So what’s the issue?
Story-Point estimation is for estimating effort for work that team will be doing in the coming days. Estimates are provided by a team collectively considering work size, complexity, and uncertainty. Fibonacci series or T-Shirt sizing are common ways to express this. It is a complete system and doesn’t require to be get converted in days or hours. We still try to change in hours/days and create a mess out of it because we are used to hours/days, not because we can’t live without it. It is similar to what I do with my son’s report card. My son is fine with the grading system, and he understands it very well. It is a problem with me, because I have used a percentile system in the past and find myself most comfortable with it. I need to learn why schools adopted this grading system and what problem they are trying to solve by it. Once I understand the purpose, then this debate will stop automatically. In the past, I knew why a bell-curve based performance system is terrible for my team, and we did better after removing that system. Similarly, I am learning why the point-based system is right for my team.
Remember, days or hours are not harmful if we consider the complexity, uncertainty, and flexibility based on individual skills and knowledge. A blog on this is on the way.