- The video discusses how to prevent estimating software tasks that make you uncomfortable
- Estimating work inaccurately can lead to burnout and overtime
- Clear communication about unknowns is important when estimating
- Refusing to estimate a large quantity of work is recommended
- Scrutinize requirements and find any holes or unanswered questions
- Clearly communicate what the software will do and set clear acceptance criteria
- Set a time box for researching or exploring unfamiliar technologies or components
- Communicate to stakeholders the reason for refusing an estimate is to avoid putting them in a difficult position
- Remind stakeholders of past projects that were late to emphasize the importance of accurate estimation.

- Remind stakeholders of past projects that were late or unsuccessful
- Stakeholders often forget about past failures and have unrealistic expectations
- Estimates are often wrong and projects often go late or fail to deliver
- Remind stakeholders of past project experiences to set realistic expectations
- Build a strong relationship with stakeholders to effectively communicate and manage expectations

When someone comes to you for an estimate of a software task, do you feel uneasy?

Incorrect estimates can be one of the biggest sources of stress for software developers.

In this video, I share some tips that will help you have better success rates when estimating software.

Though you may not be able to get out of estimating altogether (#noestimates), you can minimize the damage.

Subscribe for more videos about Healthy Software Development: https://www.youtube.com/c/JaymeEdwardsMedia?sub_confirmation=1

Related Videos:

"Software Estimation: Trading Effort For Outcomes": https://www.youtube.com/watch?v=9okWXp8z4Y0

"Agile Project Management: Is It Stopping You From Being Agile?": https://www.youtube.com/watch?v=UCtdh7Oa8hE

"How To Say "No" To Software Project Requests: 
https://www.youtube.com/watch?v=gGTOPoxVFsE

#programming #career #estimation

Hi, Jamie from JamieEdwards.com again and today I want to talk to you about how you can prevent estimating software tasks that you feel uncomfortable about.

By the end of this video, I hope to give you some tips that will help you maybe be a little bit more successful when you're put into this situation.

It's really common in this industry And I found earlier in my career, usually it was just a result of me not knowing how to set good expectations and having a good contract with whoever was asking me to estimate the work.

So 1 of the main reasons why I think a lot of software developers, myself included, are really passionate about this subject, and you've heard of the no estimates movement that's really popular where a lot of people talk about this as well, is it's 1 of the biggest causes of burnout for software developers.

If you estimate some work and your estimate turns out to be wrong, many immature software companies will basically force you to work overtime and bend over backwards to meet your original estimate.

They really don't understand the meaning of the word estimate, which really just means it's not going to be accurate all the time.

So you can go back and watch the video I did on software estimation at the very beginning of my channel.

This video is kind of a long rambling video, but There's a lot of education in there and some tips I think you can use.

If you need to communicate to your stakeholder, why is it a bad idea to estimate a large quantity of work?

And if you're at a company that's doing more of waterfall type of software development, or maybe they're using an Agile or Scrum approach, but they force you to estimate the entire backlog before people start work, go back and watch that video.

That might give you some tips on how you can actually communicate to your stakeholder and educate them about why that just doesn't work and it actually puts you in a really dangerous situation and puts him in a dangerous situation.

So ultimately, I want you to make sure you understand that this video is not gonna tell you essentially to never estimate anything.

You're gonna have to estimate some work typically because whoever you're doing software development for they have to go out and get budget and To approve budget they have to have some idea of what they're gonna spend now I'm not a big advocate of percent Complete budgeting and things like that and that's a whole nother topic.

I've talked about that in some of my other videos But at the end of the day, it's inevitable that you as a software developer or a product manager or a tester or a DevOps person You know anybody who's working together again the people who are watching this channel, if you're out there working to deliver software for customers, inevitably, you're going to be asked to do some kind of estimation.

So the first thing that I would recommend that you learn to do well when you're put into a situation where somebody asks you to estimate something and you feel uncomfortable about it is to be very clear with the other person about the unknowns.

So I often found when I was asked to estimate something and I was really uncomfortable with it, it was usually because I didn't have enough detail about what was being estimated.

I find many subject matter experts or business analysts or project managers or product managers, even though they understand their market fairly well, usually better than you, hopefully, as a software developer, and even though they consider themselves detail-oriented, and maybe they've went to Scrum Master training, or they've went to training on how to do business analysis, you as a software developer, you're gonna know more about the ins and the outs of the things that you need answers to to actually estimate something.

And I often would get very frustrated when I'd be on a project and somebody would come to me with a huge requirements document and be like here estimate this and my first kind of response would be just to get upset and feel like there's no way I can estimate all of this and helping to deal with that the first thing you can do Is really just to refuse to estimate a large quantity of work.

You can go back and watch some of the videos I've done on lean software development earlier in the in the channel about why this is just a bad idea in general But assuming you can get the other person to agree.

Okay, we don't want to estimate our whole project.

You're still going to need to estimate something and when you get those requirements handed to you or user mock-ups or user stories or whatever format you get the thing shared with you that you need to estimate, you need to look at it and try to find holes in it.

Think of it like you're almost like a lawyer and you're looking at, this is the thing they're asking you to build, and you wanna look at it with intense scrutiny and try to think, is there anything they haven't considered?

Are there any questions I have about this when I go to develop this that if I don't get these questions answered I can't actually commit to an estimate, you know, some companies that are earlier on in their sort of agile transformation journey They look at it like and I've actually heard bad advice like this from some agile coaches out there, that all you need to do is write a user story on your backlog and the developers will figure it out in the middle of the sprint what all the details are.

This is actually a horrible idea In my opinion because it puts you as a software developer in a position where there's no strong Contract between you and what you're on the hook for and what the business expects of you So you actually need to get clear about exactly?

What the software or the task you're going to build needs to do before you commit to any kind of estimate.

Now again, going back to my definition of estimates, it's a number that you provide and I won't get into whether it's story points or hours, you know, The debate rages on with that, but whatever you share, you need to feel comfortable that you're not going to get put into a situation where the business is going to interpret what you committed to as differently than what you had in your mind.

So a lot of software developers hate documentation.

They hate user requirements, you know, testing, some of the things that are required just to build quality software, they really just want to sit at their computer and write code and kind of be left alone.

But the reality is if you have that kind of attitude, you're not going to really work very well with the larger team and you're actually putting yourself into a very dangerous situation where if you don't learn to be more detailed about that the business and other people can basically Walk all over you and make your life a living hell because you're gonna do a lot of overtime because you simply didn't take the time to understand the requirements better.

So just make sure anytime you're handed any work that you need to commit to, you clearly communicate to the business, this is exactly what the software is gonna do.

It's not gonna do anything that isn't in whatever we've used to describe it And I would recommend you go learn a little bit about acceptance criteria I think that's really the best format that you can write requirements in it's better than use cases It's better than user stories.

I mean including the data that's needed to do it Like if you're filling out a form, what exact values are we gonna put in there?

If you're building some sort of data transformation engine, what are the exact data values that we expect are going to go into this processing of some sort and come out?

Not just these open-ended statements like, John uploads a document, it transforms it, and the result comes out.

I mean how can you agree to commit to something like that?

The second thing I would really recommend that you do is to set a time box for anything that you're uncomfortable and that you need to discover.

So it's very common that you're going to be asked to do some work using a technology let's say you've never worked with or maybe a third-party component or maybe you're working at a company where the products you work with there's multiple teams and you need to use something that another team's building that either isn't done or you've never worked with before.

Well, rather than putting yourself on the hook to deliver something that you're dependent on that other team for, you need to actually estimate, and by estimate I mean set a time box for an amount of time that you're gonna spend basically researching or experimenting or exploring what is it gonna take for me to understand enough about what I'm interfacing with that then I can estimate it.

So really you're just saying I'm gonna pick a fixed amount of time to try to understand what I've been asked to estimate.

Now some companies will really get frustrated about this.

They want to just push you into, look just give us a number so that we can commit it to management.

And that leads me to my next step which is that you really want to communicate to whoever is asking you to do this estimation that the reason why you're uncomfortable estimating at this point is because you don't wanna put them in a situation with their boss where they're late and they look bad.

And so anytime I've found that I have to refuse an estimate for someone, it often gets down to how can I help them feel comfortable that I'm not trying to be combative?

I'm not trying to get out of getting the work done.

I'm trying to make sure they don't get into a situation Where now they're under pressure and I am under pressure because the estimate was off So the way that you can help do that is just again clear the floor make sure the other person it's relationship building understands the reason why I'm declining this estimate.

And I'm asking you to, let's say, do a research spike or some exploratory discovery work within a time box, is because I don't want to put you into a situation where you're in jeopardy with your reputation with your stakeholder.

The last step that I'll give you that you can use that has worked really well for me as a consultant on consulting engagements is to remind them of projects or work that has been late in the past.

In the moment of kicking off a new project, or maybe the stakeholder who's come to you to ask you to do some work, they're under pressure to get the engineering team to give them a number or a budget for what work needs to get done.

It's very common for them to forget completely about every other project they've worked on in their career that's failed and try to put the rose-colored glasses on and think, well, maybe this team's better than other teams I've worked with before.

In my experience, and I've shared this in other videos, it is more common that estimates are wrong than that they are right.

And it's more common that projects go late or they're on time but they don't deliver to their promises than that they do.

And I think anyone even who's not doing software development, who's maybe not doing the work on the ground but they're managing the effort.

But you have to bring that to the forefront of their mind when they come to you to ask you to estimate something.

So you know what I've done sometimes is as a consultant I'll get brought on to estimate a new project that a client wants and I'll ask them a little bit about past projects they've worked on and how well the estimating and sort of scoping process for that project up front matched how long it really took to get the work done.

Now this is that companies again that don't have a truly agile and lean culture that they're still you know maybe doing daily stand-ups and having scrums but culturally it's really still kind of like waterfall they want to predict everything They want to do everything up front and know exactly how long it's it's gonna Take and how much it's gonna cost Well, if you can remind that person that you know what the work that you did in the past didn't match effort-wise What was scoped up front you can help them understand?

Why would you expect that to be different here, and that may sort of break them out of the urgency that they might feel to get back to their boss with a number.

And you can go back and watch my video I did yesterday on how to say no to other people with more grace and that'll give you some tips on getting through to this person and getting them to agree to talk to their boss about maybe resetting expectations on how estimation is done.

But I find if you don't build a really strong relationship with the person who's asking you to do the estimation, you could follow all the steps I just gave you and still run into problems.

You really need to have a strong relationship with that person, understand their desires, all the other things I talked about in that video.

So how have you dealt with refusing estimates in the past?

How have you dealt with basically breaking up large quantities of work into something smaller and having a better success rate that you don't get put into the situation where you're on the hook for something that you just clearly can't deliver.

If this is your first time watching my channel, you can subscribe if you're watching on YouTube.

I'm also on iTunes, Stitcher, and SoundCloud if you want to follow me and listen as a podcast, and you can like me on Facebook.


Speaker 0: Hi, Jamie from JamieEdwards.com again and today I want to talk to you about how you can prevent estimating software tasks that you feel uncomfortable about. By the end of this video, I hope to give you some tips that will help you maybe be a little bit more successful when you're put into this situation. It's really common in this industry And I found earlier in my career, usually it was just a result of me not knowing how to set good expectations and having a good contract with whoever was asking me to estimate the work. So 1 of the main reasons why I think a lot of software developers, myself included, are really passionate about this subject, and you've heard of the no estimates movement that's really popular where a lot of people talk about this as well, is it's 1 of the biggest causes of burnout for software developers. If you estimate some work and your estimate turns out to be wrong, many immature software companies will basically force you to work overtime and bend over backwards to meet your original estimate.

They really don't understand the meaning of the word estimate, which really just means it's not going to be accurate all the time. So you can go back and watch the video I did on software estimation at the very beginning of my channel. This video is kind of a long rambling video, but There's a lot of education in there and some tips I think you can use. If you need to communicate to your stakeholder, why is it a bad idea to estimate a large quantity of work? And if you're at a company that's doing more of waterfall type of software development, or maybe they're using an Agile or Scrum approach, but they force you to estimate the entire backlog before people start work, go back and watch that video.

That might give you some tips on how you can actually communicate to your stakeholder and educate them about why that just doesn't work and it actually puts you in a really dangerous situation and puts him in a dangerous situation. So ultimately, I want you to make sure you understand that this video is not gonna tell you essentially to never estimate anything. You're gonna have to estimate some work typically because whoever you're doing software development for they have to go out and get budget and To approve budget they have to have some idea of what they're gonna spend now I'm not a big advocate of percent Complete budgeting and things like that and that's a whole nother topic. I've talked about that in some of my other videos But at the end of the day, it's inevitable that you as a software developer or a product manager or a tester or a DevOps person You know anybody who's working together again the people who are watching this channel, if you're out there working to deliver software for customers, inevitably, you're going to be asked to do some kind of estimation. So the first thing that I would recommend that you learn to do well when you're put into a situation where somebody asks you to estimate something and you feel uncomfortable about it is to be very clear with the other person about the unknowns.

So I often found when I was asked to estimate something and I was really uncomfortable with it, it was usually because I didn't have enough detail about what was being estimated. I find many subject matter experts or business analysts or project managers or product managers, even though they understand their market fairly well, usually better than you, hopefully, as a software developer, and even though they consider themselves detail-oriented, and maybe they've went to Scrum Master training, or they've went to training on how to do business analysis, you as a software developer, you're gonna know more about the ins and the outs of the things that you need answers to to actually estimate something. And I often would get very frustrated when I'd be on a project and somebody would come to me with a huge requirements document and be like here estimate this and my first kind of response would be just to get upset and feel like there's no way I can estimate all of this and helping to deal with that the first thing you can do Is really just to refuse to estimate a large quantity of work. You can go back and watch some of the videos I've done on lean software development earlier in the in the channel about why this is just a bad idea in general But assuming you can get the other person to agree.

Okay, we don't want to estimate our whole project. We're not doing waterfall. You're still going to need to estimate something and when you get those requirements handed to you or user mock-ups or user stories or whatever format you get the thing shared with you that you need to estimate, you need to look at it and try to find holes in it. Think of it like you're almost like a lawyer and you're looking at, this is the thing they're asking you to build, and you wanna look at it with intense scrutiny and try to think, is there anything they haven't considered? Are there any questions I have about this when I go to develop this that if I don't get these questions answered I can't actually commit to an estimate, you know, some companies that are earlier on in their sort of agile transformation journey They look at it like and I've actually heard bad advice like this from some agile coaches out there, that all you need to do is write a user story on your backlog and the developers will figure it out in the middle of the sprint what all the details are.

This is actually a horrible idea In my opinion because it puts you as a software developer in a position where there's no strong Contract between you and what you're on the hook for and what the business expects of you So you actually need to get clear about exactly? What the software or the task you're going to build needs to do before you commit to any kind of estimate. Now again, going back to my definition of estimates, it's a number that you provide and I won't get into whether it's story points or hours, you know, The debate rages on with that, but whatever you share, you need to feel comfortable that you're not going to get put into a situation where the business is going to interpret what you committed to as differently than what you had in your mind. So a lot of software developers hate documentation. They hate user requirements, you know, testing, some of the things that are required just to build quality software, they really just want to sit at their computer and write code and kind of be left alone.

But the reality is if you have that kind of attitude, you're not going to really work very well with the larger team and you're actually putting yourself into a very dangerous situation where if you don't learn to be more detailed about that the business and other people can basically Walk all over you and make your life a living hell because you're gonna do a lot of overtime because you simply didn't take the time to understand the requirements better. So just make sure anytime you're handed any work that you need to commit to, you clearly communicate to the business, this is exactly what the software is gonna do. It's not gonna do anything that isn't in whatever we've used to describe it And I would recommend you go learn a little bit about acceptance criteria I think that's really the best format that you can write requirements in it's better than use cases It's better than user stories. It really clearly defines. What's the software gonna do?

What values are we gonna provide to it? What exactly is the user gonna do? I mean including the data that's needed to do it Like if you're filling out a form, what exact values are we gonna put in there? If you're building some sort of data transformation engine, what are the exact data values that we expect are going to go into this processing of some sort and come out? Not just these open-ended statements like, John uploads a document, it transforms it, and the result comes out.

I mean how can you agree to commit to something like that? The business can walk all over you. The second thing I would really recommend that you do is to set a time box for anything that you're uncomfortable and that you need to discover. So it's very common that you're going to be asked to do some work using a technology let's say you've never worked with or maybe a third-party component or maybe you're working at a company where the products you work with there's multiple teams and you need to use something that another team's building that either isn't done or you've never worked with before. Well, rather than putting yourself on the hook to deliver something that you're dependent on that other team for, you need to actually estimate, and by estimate I mean set a time box for an amount of time that you're gonna spend basically researching or experimenting or exploring what is it gonna take for me to understand enough about what I'm interfacing with that then I can estimate it.

So really you're just saying I'm gonna pick a fixed amount of time to try to understand what I've been asked to estimate. Now some companies will really get frustrated about this. They want to just push you into, look just give us a number so that we can commit it to management. And that leads me to my next step which is that you really want to communicate to whoever is asking you to do this estimation that the reason why you're uncomfortable estimating at this point is because you don't wanna put them in a situation with their boss where they're late and they look bad. And so anytime I've found that I have to refuse an estimate for someone, it often gets down to how can I help them feel comfortable that I'm not trying to be combative?

I'm not trying to get out of getting the work done. I'm trying to make sure they don't get into a situation Where now they're under pressure and I am under pressure because the estimate was off So the way that you can help do that is just again clear the floor make sure the other person it's relationship building understands the reason why I'm declining this estimate. And I'm asking you to, let's say, do a research spike or some exploratory discovery work within a time box, is because I don't want to put you into a situation where you're in jeopardy with your reputation with your stakeholder. The last step that I'll give you that you can use that has worked really well for me as a consultant on consulting engagements is to remind them of projects or work that has been late in the past. In the moment of kicking off a new project, or maybe the stakeholder who's come to you to ask you to do some work, they're under pressure to get the engineering team to give them a number or a budget for what work needs to get done.

It's very common for them to forget completely about every other project they've worked on in their career that's failed and try to put the rose-colored glasses on and think, well, maybe this team's better than other teams I've worked with before. In my experience, and I've shared this in other videos, it is more common that estimates are wrong than that they are right. And it's more common that projects go late or they're on time but they don't deliver to their promises than that they do. And I think anyone even who's not doing software development, who's maybe not doing the work on the ground but they're managing the effort. They know this sort of subconsciously.

They've been through it. They remember it. But you have to bring that to the forefront of their mind when they come to you to ask you to estimate something. So you know what I've done sometimes is as a consultant I'll get brought on to estimate a new project that a client wants and I'll ask them a little bit about past projects they've worked on and how well the estimating and sort of scoping process for that project up front matched how long it really took to get the work done. Now this is that companies again that don't have a truly agile and lean culture that they're still you know maybe doing daily stand-ups and having scrums but culturally it's really still kind of like waterfall they want to predict everything They want to do everything up front and know exactly how long it's it's gonna Take and how much it's gonna cost Well, if you can remind that person that you know what the work that you did in the past didn't match effort-wise What was scoped up front you can help them understand?

Why would you expect that to be different here, and that may sort of break them out of the urgency that they might feel to get back to their boss with a number. And you can go back and watch my video I did yesterday on how to say no to other people with more grace and that'll give you some tips on getting through to this person and getting them to agree to talk to their boss about maybe resetting expectations on how estimation is done. But I find if you don't build a really strong relationship with the person who's asking you to do the estimation, you could follow all the steps I just gave you and still run into problems. You really need to have a strong relationship with that person, understand their desires, all the other things I talked about in that video. So how have you dealt with refusing estimates in the past?

How have you dealt with basically breaking up large quantities of work into something smaller and having a better success rate that you don't get put into the situation where you're on the hook for something that you just clearly can't deliver. Leave me your comments below. If this is your first time watching my channel, you can subscribe if you're watching on YouTube. I'm also on iTunes, Stitcher, and SoundCloud if you want to follow me and listen as a podcast, and you can like me on Facebook. So until next time, thanks.

See all Healthy Software Developer transcripts on Youtube

Programming Estimation: Estimate Software Tasks With Caution