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.
Introduction
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:
- The given-section: In this section we prepare all boundary conditions of our software system, so that the test stay deterministic
- The when-section: A part of the software-system is executed
- 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:
- The automated ones
- 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.
Benefits
- 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.
Limitations
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:
- The user-interface needs a additional input-field for the new property
- The RESTfull-API must handle the new property
- The ABAP-update-function-module must handle the new property
- 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.
Conclusion
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.
