Always been curious how “workload” is assigned and estimated for software engineers.
In: 92
I am a software engineer and certified SCRUM master.
The answer is very poorly.
The trick is to spread out the bad estimates so the badness cancels out and on average you get something approaching accurate.
The SCRUM alliance recommends having the engineers each give an estimate of how many “points” a task will take. Then taking an average. So probably you’ll get some rough consensus on how many points a task will take.
How long do you take to do a point? Nobody knows, this will change from team to team, that’s literally the reason we’re calling them points rather than something like days or hours.
So at the end of a certain amount of time, we count the total points of all the tasks done.
This gives a rough estimate of how much stuff the team can do in the period of time (a sprint).
So what if the whole team put really big or really small number on their points? This will mean that they’ll also do a huge/tiny number of points per sprint, so you’ll know how much they’ll do the next time.
What if they’re real good at some stuff, but bad at others and they give them the same points? Well them being wrong in both places will cancel each other out. Ditto with the team members being real good/real bad at their jobs.
Of course literally nobody does it right, but it’s fun to dream about what could be.
Latest Answers