Skip to Content
Personal Insights
Author's profile photo Johannes Gerbershagen

Integrate sustainability in your estimation

In this blog-post i want to show you some ideas how to integrate sustainability into effort estimations. These estimations can be applied to software development projects.


Sustainable development comes with many benefits, but it’s often neglected due to close project deadlines in classical waterfall projects or due to small budgets.
Of course developing a clean greenfield project is slower and more time consuming than developing in the quick and dirty manner. Test-automation, code-reviews, refactorings, behavior-driven-development etc. is time consuming and in many commercial projects time means money.
But these workflows are essential to reduce technical debts and with some experience they are calculable.

The idea

Behavior-driven-development (BDD) is primary based on the idea, that we split one test in three sections:

  1. The given-section: In this section we prepare all boundary conditions of our software system, so that the test stay deterministic
  2. The when-section: A part of the software-system is executed
  3. The then-section: The results the when-section has produced are verified

The given-section and the then-section should be taken from the requirements. The when-section comes from the implemented solution.

Until one test with one given, one when and one then-section passes, we need to implemented a test-method, a procedure under test, prepare the boundary-condition, run the test, refactor the procedure under test, resolve errors, run the test again until it passes, review the code.
My idea was, the ratio between the duration, that a developer needed to implement a set of requirements, and the number of single BDD-style-tests he created in this time, reflects an average personal velocity constant.

The number of BDD-style-tests should include in my opinion all tests:

  1. The automated ones
  2. The manually executed tests

The requirements, which were implemented and which could be but actually weren’t verified with a BDD-style-test, can be also included in the number of tests.
Then the personal velocity get’s more realistic.

From the personal velocity to the estimation
To estimate the project duration with this approach, we first need to split the requirements into a set of BDD-style-tests. Therefore experience with test-driven-development is helpful.
Then we multiple the number of BDD-style-tests, which we got from the last step, with the average personal velocity.


  • The estimation includes the extra efforts for develop automated tests, for refactorings and all the other stuff, which is needed to develop clean-code.
  • The actual progess can be compared with the estimated progess.
  • Changing requirements can be included in the estimation, even when the project is already in progess.

When the project is in progess, we can compare the actual efforts with estimated efforts. The estimated efforts is the product from estimated velocity and number of implemented BDD-style-tests.

A new estimation for changed requirements can be done with the same algorithm. Therefore we split the changed requirements into a set of BDD-style-tests, substract the tests, which are already implemented and which are still conform to the changed requirements, and multiple the number of tests with the average personal velocity.


This estimation-algorithm can be applied to classical greenfield waterfall projects.
Brownfield projects are more difficult to estimate, because a change on the top-level-component like the user interface often has a set of changes in the dependencies as a consequence.
Take as a example a transactional client application, which interacts with SAP through a RESTfull-API. When the user should enter an additional property in the user-interface and this property should be saved in the database-records, the application creates, every component of the application must change:

  1. The user-interface needs a additional input-field for the new property
  2. The RESTfull-API must handle the new property
  3. The ABAP-update-function-module must handle the new property
  4. The database-tables must store the new property

In my next blog-post i want to show you another idea how to estimate brownfield projects.


The average personal velocity can be an important key figure for effort estimations, which include all the extra efforts for developing in an sustainable manner. Of course this key figure is based on some assumptions and will not cover all eventualities, which happens in an software project.
But it can be a quite realistic approach for projects, that are using behavior or test-driven-development.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Nabheet Madan
      Nabheet Madan

      Johannes Gerbershagen nice post, i have few questions

      1. Most of the clients whom I have worked with the most basic concern for them is the increased estimation, practically it gets very tough to explain them the rational when the other person being a client does not understand it despite being technical. Have you faced such situation if yes were you successful in convincing them and how?
      2. Unfortunately every project has deadlines and sadly the one's deciding the deadline does not understand these concepts or benefits, how do we get around it?
      3. Reviewer lack of knowledge another constraint

      I will be really happy to know whether you are using in your projects if yes how did you manage the above mentioned points?



      Author's profile photo Johannes Gerbershagen
      Johannes Gerbershagen
      Blog Post Author


      1. I know it's difficult to convince non-technical-clients about sustainability and quality, because these topics are only recognized through their absence. The most sucessfull strategy i know, is solving as many issues as possible. Then clients start to trust you more and more and give you the chance to do it in your way, even the effort estimation is bit higher. The most software projects i maintain mainwhile i adopt as legacy projects. Then i started slowly to solve the issues, the bugs, add automated tests, refactoring the code base etc... All the stuff my predecessors ignored. After a while clients come again and ask for further improvements. So far nobody has come yet and exclude me from development. I think, they wouldn't act like this, if they believe i'm on the wrong way with this strategy.
      2. Goods question and the only answer i can give, try it with the same strategy as in point 1. Maybe the decision makers give you bit slack deadlines, when they recognize the output is more valueable.
      3. This is a common problem in the software industry. The only solution i know is education.


      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Great answer and nice blog too!

      I agree that building a trust is vital for being able to, well, do anything, actually. If people do not trust you why would they follow you and agree to your suggestions? I feel this is especially a challenge for the consultants, unless they work for a company that already built trust with the customer. The permanent workers face the same issues but the consultants frequently start off with a handicap. At least that's my experience from years of observing many SAP projects.

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Good points. Johannes already answered well to p. 1. I feel 2 and 3 are connected and this is a general challenge in development, not related specifically to the specific concept in the blog.

      To write better code (which is, in the long term, cheaper and easier to maintain), we need to learn continuously and understand new techniques / technologies that come up seemingly every day. At the same time, we have our daily work to do, working code to write. So we don't have a lot of time to learn. But if we don't learn, we do not write good code and eventually spend more time writing code inefficiently / maintaining inefficient code. And we have even less time to learn.

      As you see, it's a vicious circle breaking which can be very challenging even for someone who realizes it needs to be broken. (Let's just admit there are plenty of "lemming developers" who are perfectly happy cranking out the same code and/or don't even realize they're stuck on a wheel.) This is a complex problem that also involves incompetent managers and lack of leadership but, that aside, what can we do, as developers? Here are my thoughts.

      1. We need help to understand what is the most practical solution for specific scenarios. I frequently struggle myself with keeping balance between what I can achieve in the given time with given information and "what would Matthew Billingham  say if I posted this code on SCN". 🙂 We need to know what's really important / non-negotiable and what we could let slide if push comes to shove. Simple example: the SAP SALV demo report is a procedural program. There are enormous benefits to using SALV vs. previous ALV models but my first forays into it were not object-oriented programs (based on the demo) because it was more important, in my view, to switch to SALV. If I pursued bigger change, I'd run a risk of simply running out of time and simply copy-pasting some REUSE_ALV... cr*p that I knew for sure worked. Real life is full of compromises.
      2. We need more specific use cases and evidence of tangible benefits for whatever SAP and some of our SCN luminaries are proposing. Customers always complain how SAP has such pushy marketing but no one knows like what exactly would anyone gain by switching to S/4 HANA. (The [in]famous WIIFM.) "Faster" and "better" are not the numbers. But we do the same thing on SCN. That's why I comment on every other ABAP blog here asking for a specific business case (hardly anyone replies btw). It's not difficult to notice that this type of information (what specific business problem it solved, what value was gained, etc.) is missing from I'd say 99% of the content. It's mostly missing from SAP events too. There is no way I can "sell" any improvement to my manager without this information. Yet I need their support to break the vicious cycle above.
      3. We simply need more and better real, working ABAP examples. Last year, I went to TechEd, ASUG meetings, read countless blogs, read (at least partially) several books, etc. It's not like all of that was useless but the most value gained was the code I copied from two Github projects: ABAP Logger from Eric Peterson (no longer active?) and SAP Gateway services example shared by Graham Robinson . Not only I could just copy-paste the code, run it and actually use it to build my own programs, but I could also read it and learn how to do things better or at least differently. I want to do things, not just read or hear about them. And I want to do things for my work, not in some perfect-sphere-vacuum-cloud environment. That kind of help is what I think is desperately needed to start breaking the cycle.

      Thank you.

      Author's profile photo Matthew Billingham
      Matthew Billingham

      “(Let’s just admit there are plenty of “lemming developers” who are perfectly happy cranking out the same code and/or don’t even realize they’re stuck on a wheel.)”

      Lemmings go off cliffs. Perhaps “hamster developers”. ?

      WWMC? What Would Matt Code? – I like it. I think I’ll trademark it. ?

      Author's profile photo Johannes Gerbershagen
      Johannes Gerbershagen
      Blog Post Author

      Hamster developers describes it very good. I see many colleagues don't come out of their wheel. They just saw the plenty old COBOL-style solutions with huge procedures, the five chars long abbreviations etc. and think that is the way how ABAP development is done.

      The never saw and nobody tells them how ABAP development can be enhanced in the year 2020. Next week i'm going to tell some of these developers, that we couldn't accept these old COBOL-style solutions anymore and that we going the review their code continuously and expect them to improve and refactor their solutions. I'm excited about the reaction.


      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Good luck with that! 🙂 I hope most people genuinely want to change and just need some help or motivation. However, there definitely are people who just refuse to change at all. In my personal opinion, if anyone ever reaches such point they should leave the development profession for everyone's sake. But not everyone agrees...

      Author's profile photo Matthew Billingham
      Matthew Billingham

      I did that back in 2003. It generally improved coding styles. I was Head of Development then, so I wrote the standards, and then said - code reviews must be carried out to ensure these standards are met.

      Very simple standards like:

      • Well encapsulated
      • Well modularised
      • Easy to follow
      Author's profile photo Shai Sinai
      Shai Sinai

      For the matter of fact, Lemmings don't go off cliffs.

      It's just a myth (based on a faked nature movie).

      Author's profile photo Matthew Billingham
      Matthew Billingham

      Don't tell me it's a myth. I've played the game. 😉

      Author's profile photo Johannes Gerbershagen
      Johannes Gerbershagen
      Blog Post Author

      Better real working ABAP examples:


      Author's profile photo Michelle Crapo
      Michelle Crapo


      For a smaller project, I'm not sure how it would work.  Like Nabheet Madan it is probably lack of personal knowledge.

      I also think you would have to balance what the change is with what the effort to fixing the program would be.  If it would take you 2 hours to do a quick change or 5 days to fix it, I couldn't justify the five days.  Probably because it isn't really a project.  Correct?

      I can see the advantage.  But I struggle with how to implement it.