Hours before a proposal deadline, a partner at a technology services company was about to make a mistake that would cost him his job and his firm lots of money.
As he was going through the resource allocation plan, instead of padding the estimates by a factor of two, the partner ended up dividing the estimates in half — a mistake of omission that managed to go unnoticed. It cost millions of dollars and ultimately, for the partner, their job.
When it comes down to people making decisions on capital allocation, it inevitably becomes “how long will it take?” and “how much will it cost?”
A little abstraction in between is story points → it is an abstraction that is not time, but a fibonacci series that can show s, m, l and xl in terms of effort.
The key rule for story points is to compare teams against themselves, but comparing ourselves to others is a problem most people have but fail to acknowledge. Another reality as an early stage entrepreneur is that many teams are changing quite often. 🤷♂️
When someone asks me how long something will take, here is what I think about:
Most people will answer the “how long will it take” question with 🤷♂️.
To avoid looking stupid, one way is to pad our estimates. Then (maybe) also schedule a lot of meetings, touch-points etc. in case anyone calls us out on it.
See below for an illustration of what just three levels of management in estimation adds, regardless of the methodology being applied.
Software estimators regularly pad their efforts by more than 40% and the number only grows with the size of the organization.
In this post, I’ve tried to understand how story points work and if they are a better alternative to time based estimates with a confidence level.
I struggle to understand why people are die-hards of a software development methodology. Each has principles for high performing teams that can be used for the team & project situation
We’ve seen the rise of agile and scrum, and the gradual farewell to waterfall for good reasons to make way for sprint/agile. Along with the sprint/agile/scrum/kanban/xp processes has also arrived the idea of story points. Story points are not well understood by most people who are planning or doing the work.
Estimates and Sizing in the Real World
I asked about 50 people I trust working in senior software development positions, who shared the following choice quotes:
“We usually estimate twice the size, but are still wrong 90% of the time.”
“We have tried points sizing uncountable times… Devs always return back to time based. Exactly the discussion yesterday with an executive manager: says time is the absolute measure which everyone understands, even client pays based on that why should I do story points.. I was like yes but… Agile, Trust, Self Adjusting teams working towards common goal, etc etc … All looked useless stuff”
It works for people at mature organizations:
So naturally, I asked why they moved back and got the following answer:
Abstracting away the complexity with story points
There is value in abstracting away the complexity of a software development process. In a very large company, it also makes it harder to get called out for not doing anything useful.
So here is how the story points abstraction may have been formed, according to the guy who likely invented story points →
days → ideal days (when people leave you alone to work) → ideal days (which became confusing) → story points
Story points with distributed teams
Story points do not work well for:
- Teams whose members are geographically dispersed or part-time: In Scrum, developers should have close and ongoing interaction, ideally working together in the same space most of the time. While recent improvements in technology have reduced the impact of these barriers (e.g., being able to collaborate on a digital whiteboard), the Agile manifesto asserts that the best communication is face to face.
- Teams whose members have very specialized skills: In Scrum, developers should have T-shaped skills, allowing them to work on tasks outside of their specialization. This can be encouraged by good Scrum leadership. While team members with very specific skills can and do contribute well, they should be encouraged to learn more about and collaborate with other disciplines.
- Products with many external dependencies: In Scrum, dividing product development into short sprints requires careful planning; external dependencies, such as user acceptance testing or coordination with other teams, can lead to delays and the failure of individual sprints.
- Products that are mature or legacy or with regulated quality control: In Scrum, product increments should be fully developed and tested in a single sprint; products that need large amounts of regression testing or safety testing (e.g., medical devices or vehicle control) for each release are less suited to short sprints than to longer waterfall releases.
At the end it usually boils down to “how long will it take?”
For large companies managing an army of engineers, kanban & story points work well. Also abstracts away the need for multiple layers of management. For small teams, we just want to make bets on what to make with a confidence level and expected ROI.
For small teams that want flexibility while getting things done on time, they are better off using time estimates with a confidence level in a scrum way. Here is what I’ve been doing more often to get this done:
- Vision & Goals – clearly communicate goals & target
- Structure – set clear time constraint e.g. six week flights
- Shaping – estimate time & confidence level per story e.g. 2 days at 70% confidence
- Shaping – identify the value to be created
- Betting table – allocate resources based on risk appetite
Story points are not well understood when applied in real-life situations. Time is the scarce commodity, and in my experience, probabilistic estimates and actuals of time are better.
If you’d like some help with it I’m happy to share my experience & templates, etc. for how to communicate the above items to your teams.
As we move towards distributed teams, and contract workers, the cost of mistakes & padding will increase further. For high performing teams, it does not matter. Its large organizations and understaffed teams where padding hurts the most.
Do you have any experience with the above, drop a line with what you would do if you were the CEO of your small or large company.
