One of the scariest things to reply back to another human being as a Software Developer is the dreaded question:
"How long is it going to take?"
We all hope we could answer "Whatever it takes" to our managers or bosses, but we need a stable income in our lives.
Some people come up with arbitrary times, whether it's a few days, a week or two, maybe 3... but we can all agree that overshooting and getting it done sooner than expected makes us look way better than undershooting and responding with the classic:
It was more complicated than what I expected...
Some people prefer using points systems, others might argue that time intervals might be better... But ultimately, we can all agree that we all, as human, are pretty terrible at estimating.
So, how do you do it?
Oldest comments (18)
I prefer time to points, using half-day to day intervals, and overshooting when possible. If it looks like it takes longer than one week, I ask if it can be split into multiple tickets, even if both of those still are assigned in the same sprint.
A lot of times when things take longer than expected it's because you couldn't devote as much time to it in an uninterrupted way as you expected. If you got to devote as much heads down time as you think you can, things become more predictable.
So I try and over-communicate around what I think the overall circumstance is to give a picture of why something might take a certain amount of time for both me and the stakeholder. There's also a chance to de-prioritize something in that convo.
Simple. Don't do them. Ever
The estimation we use is regarding complexity, but it feels, although we are doing more or less SCRUM, like we are not doing as it should be according to it. For example, when we take a task into the next sprint, we had a discussion about the need to estimate it again (for the left effort), but if you are estimating with complexity, it possibly does not make much sense and in addition, if you already failed at estimating it completely (it has been taken into the sprint, because you thought it can be done with one), then you can ask yourself, why you would need to do that again. You can just finish it, if it just has not been estimated exactly with little difference or cancel it, if you missed a lot of important points. Maybe you actually need to have a closer look at how you create the requirements and tasks.
I think a big issue is, that you can have different people on your team with, you know, different experience and knowledge. If the team estimates, the question should also be about what you exactly estimate. You could estimate with a certain person in mind, who would do the implementation, but it seems to happen, that people only consider the task to be done and not who would do that.
I don't, but have to as I have been told by managers and supervisor. Really problematic if you are dealing with the wrong person. There are psychological factors involved that are not in your control but you have to deal with.
It's hard to tell it in advance, that's why they call them estimates. Also it's important to let other party know that you gave estimates not the absolutes.
If you hit the block just keep updating people in real-time so they can prepare themselves in advanced because if you be hard on yourself and try to spent a week trying to reach some estimate and then fail to do it because it was impossible. Then when doing weekly meeting. You talk about your issue while they were expecting great, unrealistic things and you tell them its not done. They would feel you have taken something from them. Yup, it was fantasy idea, some expectation that job would be done (
not that its not done it would take ___ time more, omg delay- their thoughts) but things aren't as simple are they? so that's something to be aware of.Just simply, "Don't promise you will give someone $200 and then don't give" because even before they get $$$ they believe they already have it, and then on the day when you have to and can't they feel you have taken $200 from them.
An admirable goal is to force every card to be at most some (small) size and then declare every card to be that size. Now you're measuring features deployed to production, rather than measuring the amount of complexity deployed 😏
I was on a team where we were tempted to try that approach, but ultimately couldn't as we had very limited control over the content of some of our cards.
Multiply everything by 10. That way you can always "underpromise and overdeliver".
That isn't possible in small companies or big ones where pm whats stuff done quickly. To maximize profit and look good in the eyes of the client...
One of best responses i read. Also quite informative. Thank you for the float Nf slack concepts.
This is a problem many need to face.
Thank you
I was usibg the idea of presuming hiw much time a task needs then addibg 45% to it. But it still didn't do a good job of creating a reasonable estimate.
What @sarthak and @leonid medovy said, are usefull information which i ll try to introduce in the estimation process.
The float and slack idea sounds good.
I wrote an article about this subject and linked to your article from it @chrisvasqm, just letting you know.