The Estimation Process is a chaotic situation we get ourselves into, it is a necessary ongoing continuous evil and you can't do anything about it, but what you do defines the outcome, sometimes you're a Kevin Flynn and sometimes you're Clu 2
1. 💡 Know your people.
Know their schedule, their strengths and weaknesses, what excites them and what brings them down, let them give you the feedback on anything that goes 10-15 days ahead of schedule.
You dont have to have a Dream Team, but you'll have to manage what you have properly If anything you estimate the outcome from people not the software itself, because the Software will not write itself (not at this time anyway) so knowing your variables will make a chaotic situation somewhat better.
They say that the enemy of Good is Perfect, well... yes but actually no, bad decisions will lead to technical debt, unless you're looking to escape to a different Company/Country/Universe before the deadline hits, you'll have to imagine what your decisions will lead to.
To be clear, there is no silver bullet, whatever works is good enough, but some things work better than others, i would start by not trying to be good, be realistic, dont try to play nice, i think that's the 101 on estimates, it is what it is, you always do your best but it's not a contest that you have to win.
You'll have to be ready to cut corners but that's not what the initial plan is in estimates, it is what happens in some cases, so if someone want to mess with your estimates get ready to pain him with the realities of what he'll have to lose (Utility from server or UI/UX features on an initial demo, all should be accounted)
2.✨ The three point estimation.
Take what is required as a feature, let's assume that it is pretty straightforward, there are no third party dependencies in terms of management to implement it, there is nothing special about it, it's all up to you (that's a pretty good scenario for most cases) You'll have to apply the days of development to the estimate in the coming form.
Result = 9 days therefore 99.9%
In this technique you'll probably say that for a straightforward feature 9 days are probably too much, you could easily make it in 6 right?
All the projects that never made it to deadlines are thinking the same thing.
If we assume that your data aint so straightforward as you progress in development, and you get updates (usually bad ones) you'll have to start cutting corners, ultimately estimates are deal making, if you start with a bad deal you'll end up with a bad deal for everybody, but if you do it right, then you can cut corners between documentation and testing without sacrificing actual utility from what is required, so... being nice is a bad deal for estimation dealing, it will bite you back, and your client.
3. 📐 Average Development pace within a scrum team
Let me tell you one thing about Scrum teams, they are often misused, and i'll let it at that.
People ignore the people factor mentioned in the start of the article, they'll give unrealistic estimations that god knows what the algorithm was behind the final date and play with numbers while rating feature complexity that is more like a guessing game (Spoiler Alert: it doesn't end well.)
They will introduce more people in a team after 2 months and they'll also expect them to adapt in miliseconds because it's the most probable outcome.
Many things can go wrong, but what can we do about it?
Calculate the average development feature pace and give it a 5 for complexity, do it with all the developers, dont expect it to be 100% accurate because people have strengths and weaknesses therefore it might not illustrate their best self, but that's exactly the point, in a way you want them to fail for your estimations to succeed.
You need to have a clue of your team's pace even if the accuracy is limited, what you think it is your actual team's pace will be even less accurate, i would say it is definitely irrelevant and will lead to trouble.
While having a glimpse of what a 5 is in terms of complexity, you'll probably have to readjust it every now and then because you guessed it, the people factor, you're dealing with people, act like it and they'll thank you for it.
I'd like to thank the Estimation Police of Luxembourg for this technique.
**Well i dont agree with this Opinion section: **
At this point some will disagree with this, they are the same ones that believe that you can define a clear scope and ignore the people factor because Marketing said so, (At the expense of mental health and worklife balance maybe) they might even see unicorns and fairies in the woods, that wont help their deadlines, being realistic will.
Thanks for Reading.
- Contact me on Twitter: ** https://twitter.com/ChasanisNickos
