Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

[Article] How to make realistic estimates when working with software development


Recommended Posts

  • Owner

Estimations for software development seem to be the bane of almost every company, but why is that really? Why is it so difficult to approximate the time and effort required when we do this all the time? There are a few reasons and in this article I will go over how I do my estimations and give you some of my experience on how you can maintain a 90% accuracy in any project.

For a good estimate you need to start with one very important thing: define if you estimate based on time to complete or  time to deliver. These are very different because the time to deliver will be substantially higher and much more prone to variations. This is because in the daily work you will be dragged into meetings, have people distracting you and so on. For good estimations we always estimate on time to complete as our basis.

Stop doing happy estimates

The worst thing you can do is making happy estimates. These are estimates based on the utopia that everything will work smoothly and you will be left in total isolation to focus. It never happens and Murphy is always present. Happy estimates may seem good because the product owner love low estimates, but they hate when you fail to deliver.

Happy estimates usually happen when an architect is stressed and throw out a guesstimate on the fly. It will almost always bite you in the butt because not only will everything seem easy to the architect, so they will underestimate it, they also never consider Murphy.

You do not estimate to be nice, you estimate to give a realistic view on when something can be available in production. If you have a hard time to stop making happy estimates, then implement this very simple rule:

"Any time that is needed beyond the time you have estimated you will do in your own time without payment"

Take your time doing estimates

An estimate is not a guesstimate that you throw out on a high level requirement. An estimate is your promise on when you can deliver and as such you should take your time and think that through. Don't sit around doing arbitrary guess work in a planning poker or play with t-shirt sizes unless you want to avoid doing any estimates at all. That type of guesstimating is for high level requirements, so make sure they stay there.

Break down the requirement and use your experience to guide you to a first number in your estimation. This estimate is how long it will actually take to sit down and build based on the requirement. Make sure that you ask questions to clarify where needed so have the information you need. This is also a good time to start working on a solution design to make sure you have considered things that may not always be apparent. For example validation of data in integrations or extending a JavaScript validation for a new form.

When we have done this, the number is still wrong, but we need it as a starting point.

Add the things you forgot

Now that you have done your estimate, many think they are done. That is rarely the case, so let us add the things that is not included yet. The most obvious problem that I see a lot is that the estimates is usually done by the most experience person, which also usually is the one that work fastest of everyone in the team. So what we do is to look at the estimate and the team, then we adjust based on what the slowest person in the team think is appropriate. This way we know that the base estimate is reasonable for everyone on the team.

The second thing we do is to consider Murphy. Things always happen and based on the complexity we increase the estimate with 20-100%. Not having room for mistakes is in itself a very big mistake. It will almost always happen and if it does not happen for this particular task we will either be able to resolve things faster than expected, or we have more time for other tasks. Either way that is a positive thing.

The third thing to look at are testing. All code should have unit tests and it is often forgotten in the estimate. You also have non-functional requirements such as loading times and browser support that you must consider. As a developer you are also responsible for testing the code and this should be added as a second estimate. For many estimates this alone will add 20-200% or even more to the estimate. This is especially true for frontend development where you often have 18+ variations just for devices and browsers.

These three very simple things easily multiply the original estimate two to three times.

Now let us consider your efficiency!

A factor that is very often overlooked is efficiency. No person in any team will ever have 100% efficiency in the sprint. I do not mean your focus level during the day, even if that also is a factor, I am talking about those pesky things that break your concentration. Things like meetings, stand-ups, code reviews and all those "I just want to ask a quick question", cost a lot of your time during the day. In my experience most teams will have an efficiency of around 40-60% depending on how often they are disturbed.

Depending on if your product owner understand estimation or not you can choose if you add the efficiency in the estimate, or if you have that as an external factor in the sprint itself. If you are new to this part of the estimation I suggest that you start with 50% efficiency and then adjust over time as you get better at estimating your efficiency.

With this step we now add a second two time multiplier and you are now close to a realistic estimate.

This may seem like a lot

This may sound like the estimates always will be very high compared to how you are working today, and you are right. This is why you always feel stressed and why you fail to deliver on promise in every sprint. It is why we invent things like story points to mitigate our inability to take responsibility for things we can't estimate properly. Realistic estimates are just that and if your estimates are far lower than what you get doing estimates this way, then remember this very simple rule:

It is always better to overestimate and over deliver than to underestimate and under deliver.

 

The Quick Summary

  1. Make estimations in actual time to complete, not arbitrary measurements.
  2. Take your time to understand the task at hand and stop guesstimating.
  3. Adjust the estimate to fit the slowest person on your team.
  4. Add task for testing and make estimation separate for that.
  5. Remember that things always go wrong, so make room for that.
  6. Make sure that your efficiency is considered and calculated into the time to deliver.


    Making good estimates is based on experience and knowledge. This means that like other skills you can get better at it. If you constantly work with arbitrary measurements like story points and you constantly fail with no change to your estimation process, then you should stop doing that. Not only will you fail at a crucial part of your work, your inability to provide accurate estimates actually cause harm in the form of stress and frustration. It is up to you if you want to spend your time in constant failure or constantly provide estimates that are realistic and dependable.

    Learning to make good estimates is not rocket science, just common sense and experience.

    So start doing it today.


    View full blog article

    Link to post
    Share on other sites
    • Replies 1
    • Created
    • Last Reply

    Top Posters In This Topic

    Popular Days

    Top Posters In This Topic

    • Owner

    I received the following comment on LinkedIn from Paolo:

    Quote

    Good article Jimi! What I would recommend is also to consider what is outside of your organisation, that generally you can't control: the customer and any 3rd party (e.g. a payment provider). Will they follow your way of working? Will they proceed at the same speed as you or slow you down? In my experience the complexity increases proportionally with the number of third parties involved.

    You only estimate what you control. This is why you estimate time to complete and not time to deliver. External factors can block your progress, but that is waiting time that is not part of your time to completion.

    This is where dependencies and risk comes in and that is something you will need to balance in the Sprint Planning and the Sprint Startup to ensure the dependencies and risk are acceptable.

    For this purpose you should always have a blocked status in your workflow so you can measure waiting periods outside your control and it is also why you should use dependencies so you can mitigate delays that could affect you.

    God point Paolo, I should write about this in another article I think 🙂

    Link to post
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
    • Similar Content

      • By Jimi Wikman
        Earlier in 2019 Atlassian presented their new cloud development platform FORGE at the Atlassian Summit. The idea is to have a tool that makes it easier and faster to develop apps for the Atlassian cloud suite using a serverless FaaS hosting platform, powered by AWS Lambda.
        This new cloud development platform will probably be a welcome tool for new app developers and if received well it will push development for cloud to the front lines. All in accordance with the business strategies Atlassian seem to push towards cloud in general.
        According to the article by Atlassian, Forge comes with three core components:
        A serverless Functions-as-a-Service (FaaS) hosted platform with Atlassian-operated compute and storage for app developers A flexible declarative UI language (Forge UI) that enables developers to build interactive user experiences across web and devices with just a few lines of code A state-of-the-art DevOps toolchain, powered by the intuitive Forge Command Line Interface (CLI).  
        A serverless Functions-as-a-Service
        The first component with the FaaS I think sounds excellent as one of the big hurdles with app development for Atlassian (and other systems) is hosting and develop the app as a separate web service. Having FORGE do the heavy lifting should make that threshold a bit lower (depending on the cost of course).
         
        Atlassian list 3 specific areas that they hope that FORGE will help with:
        Trust: As personal information goes digital, privacy, transparency, and security are more important than ever before. With Forge UI, developers and app consumers benefit from built-in, best-in-class security for apps, by default. Plus, thanks to Atlaskit, when Atlassian makes an update, your apps won’t break. Running anywhere: Atlassian customers want experiences that are consistent across their products and apps, and across their devices and web. Forge’s UI enables users to build once for both web and mobile. Moving up the stack: In general, developers aren’t concerned with where their code is running – they simply want to spend less time on implementation details of the code, and more time on providing customer value. Forge’s serverless FaaS model enables developers to write single functions rather than building entire web applications.  
        There are also other areas where FORGE can help reduce pain points and increase security.
         
        A flexible declarative UI language
        The second part I am not sure if it's a good thing or not. For anyone developing only towards cloud based Atlassian systems it is of course awesome as it makes things easier and we get a more unified design across apps as well as systems. It is when dealing with multiple ecosystems such as Server or Data Center this can become a bit complicated.
        On one hand it forces even server based apps to follow the design specifications of Forge UI, but on the other hand it can limit the app developers. Overall it should still be a good thing and as it is based on Atlaskit it should be pretty well aligned with the overall UI design for cloud.
         
        A state-of-the-art DevOps toolchain
        For the DevOps toolchain I would like to know more before making any assumptions as it seem to be based on Bitbucket pipelines that are still quite new.  I like Bitbucket Pipelines, but I would like to see if this is just a built in version of it into FORGE or if it has some changes.
        Things like defining environments within AWS Lambda and what the UI for this will look like. Is it "just" a CLI and if so, what capabilities can I expect within the CLI itself. Will this be connected to Bamboo for the build or can I choose other build tools such as TeamCity for example?
        The fact that this part is barely mentioned in the article of the presentation is a bit of warning flag for me. If it is state-of-the-art, then please show me the tool chain and give me an example of a simple code update from development to production. Still, this is just me being a bit nit-picky as I am sure there are already videos out there for this or they will come soon enough.
        Overall I think this will be a bit of change for many app developers today, but a good change.
         
        Welcome to the Forge - Presentation at Atlassian Summit 2019
         
        Personally I think this is a great thing that will help app developers a lot. Old app developers might need a while to adjust, but in the long run I think it is a good thing. Adding this service not only ensure that things get more uniform in terms of design and coding, but it also will provide great insight into how a controlled DevOps toolchain is perceived outside of their own company.
        I look forward to learn more about Atlassian Forge that is currently in Closed Beta that you can sign up for here.
         
        What do you think of Atlassian Forge so far?
         
         

        View full blog article
      • By Jimi Wikman
        Earlier in 2019 Atlassian presented their new cloud development platform FORGE at the Atlassian Summit. The idea is to have a tool that makes it easier and faster to develop apps for the Atlassian cloud suite using a serverless FaaS hosting platform, powered by AWS Lambda.
        This new cloud development platform will probably be a welcome tool for new app developers and if received well it will push development for cloud to the front lines. All in accordance with the business strategies Atlassian seem to push towards cloud in general.
        According to the article by Atlassian, Forge comes with three core components:
        A serverless Functions-as-a-Service (FaaS) hosted platform with Atlassian-operated compute and storage for app developers A flexible declarative UI language (Forge UI) that enables developers to build interactive user experiences across web and devices with just a few lines of code A state-of-the-art DevOps toolchain, powered by the intuitive Forge Command Line Interface (CLI).  
        A serverless Functions-as-a-Service
        The first component with the FaaS I think sounds excellent as one of the big hurdles with app development for Atlassian (and other systems) is hosting and develop the app as a separate web service. Having FORGE do the heavy lifting should make that threshold a bit lower (depending on the cost of course).
         
        Atlassian list 3 specific areas that they hope that FORGE will help with:
        Trust: As personal information goes digital, privacy, transparency, and security are more important than ever before. With Forge UI, developers and app consumers benefit from built-in, best-in-class security for apps, by default. Plus, thanks to Atlaskit, when Atlassian makes an update, your apps won’t break. Running anywhere: Atlassian customers want experiences that are consistent across their products and apps, and across their devices and web. Forge’s UI enables users to build once for both web and mobile. Moving up the stack: In general, developers aren’t concerned with where their code is running – they simply want to spend less time on implementation details of the code, and more time on providing customer value. Forge’s serverless FaaS model enables developers to write single functions rather than building entire web applications.  
        There are also other areas where FORGE can help reduce pain points and increase security.
         
        A flexible declarative UI language
        The second part I am not sure if it's a good thing or not. For anyone developing only towards cloud based Atlassian systems it is of course awesome as it makes things easier and we get a more unified design across apps as well as systems. It is when dealing with multiple ecosystems such as Server or Data Center this can become a bit complicated.
        On one hand it forces even server based apps to follow the design specifications of Forge UI, but on the other hand it can limit the app developers. Overall it should still be a good thing and as it is based on Atlaskit it should be pretty well aligned with the overall UI design for cloud.
         
        A state-of-the-art DevOps toolchain
        For the DevOps toolchain I would like to know more before making any assumptions as it seem to be based on Bitbucket pipelines that are still quite new.  I like Bitbucket Pipelines, but I would like to see if this is just a built in version of it into FORGE or if it has some changes.
        Things like defining environments within AWS Lambda and what the UI for this will look like. Is it "just" a CLI and if so, what capabilities can I expect within the CLI itself. Will this be connected to Bamboo for the build or can I choose other build tools such as TeamCity for example?
        The fact that this part is barely mentioned in the article of the presentation is a bit of warning flag for me. If it is state-of-the-art, then please show me the tool chain and give me an example of a simple code update from development to production. Still, this is just me being a bit nit-picky as I am sure there are already videos out there for this or they will come soon enough.
        Overall I think this will be a bit of change for many app developers today, but a good change.
         
        Welcome to the Forge - Presentation at Atlassian Summit 2019
         
        Personally I think this is a great thing that will help app developers a lot. Old app developers might need a while to adjust, but in the long run I think it is a good thing. Adding this service not only ensure that things get more uniform in terms of design and coding, but it also will provide great insight into how a controlled DevOps toolchain is perceived outside of their own company.
        I look forward to learn more about Atlassian Forge that is currently in Closed Beta that you can sign up for here.
         
        What do you think of Atlassian Forge so far?
         
         
      • By Jimi Wikman
        Polypane is a browser built from the ground up to create websites and apps and it just released version 2.1 with some nice new features. The aim is to give you better insights into your site and make the entire developer/designer workflow faster and the features to do so is pretty great.
        What's new?
        Quick list of the major new features:
        Live CSS Edit all panes at the same time Social media previews See what your page looks like when shared on Facebook, Slack, Twitter and LinkedIn. Meta info Get a full overview of all your meta tags Handoff / browse Use Avocode, Zeplin and more directly in Polypane Workspaces UI Quickly switch between your favorite pane sets Beyond that, we also added network throttling, new and improved overlays, better indicators, ways to detect when your site is shown in Polypane, speed improvements, and many more smaller features.
        You can read all the changes here:
        Polypane 2.1: Edit all your panes at the same time | Polypane browser for dev & design
        POLYPANE.APP With Polypane, we want to give you better insights into your site and make the entire developer/designer workflow faster… ---
        If you do not know what Polypane is, then maybe this short video can help explain it.
         
      • By Jimi Wikman
        Polypane is a browser built from the ground up to create websites and apps and it just released version 2.1 with some nice new features. The aim is to give you better insights into your site and make the entire developer/designer workflow faster and the features to do so is pretty great.
        What's new?
        Quick list of the major new features:
        Live CSS Edit all panes at the same time Social media previews See what your page looks like when shared on Facebook, Slack, Twitter and LinkedIn. Meta info Get a full overview of all your meta tags Handoff / browse Use Avocode, Zeplin and more directly in Polypane Workspaces UI Quickly switch between your favorite pane sets Beyond that, we also added network throttling, new and improved overlays, better indicators, ways to detect when your site is shown in Polypane, speed improvements, and many more smaller features.
        You can read all the changes here:
        Polypane 2.1: Edit all your panes at the same time | Polypane browser for dev & design
        POLYPANE.APP With Polypane, we want to give you better insights into your site and make the entire developer/designer workflow faster… ---
        If you do not know what Polypane is, then maybe this short video can help explain it.
         

        View full blog article
      • By Victor Aflarenko
        Hi! I'm Victor Aflarenko, a Swedish guy who is very passionate about music and graphic design.
        I love what I do, this is my passion. My inspiration comes from everything between music and buss rides.

    ×
    ×
    • Create New...