How to Estimate Software Projects in A Test-Driven Development Environment

DZone 's Guide to

How to Estimate Software Projects in A Test-Driven Development Environment

Defining, planning, iterating, and repetition are the four basic tenets of making sure that you have an accurate estimation strategy.

· Agile Zone ·
Free Resource

The ability to qualitatively estimate software development time expenditures is one of the key skills of a good development manager and/or service provider. Erroneous predictions of project timeframes and deadlines for completing mission-critical tasks are the main sources of pain and critical issues for the customer.

Practices that allow us to rely not only on our gut feelings and guesswork but on something measurable and time-bound are well-known to software developers. One of them is a proper project planning. While planning is quite a routine job, doing it the right way requires commitment and well-defined actions.

Create Functional Descriptions

The basis of any good planning is a well-formulated description of the functionality that needs to be implemented. The best way to do so is to create user stories and/or behavior patterns (use cases) such as this one:

As a user, I want to pay for my order with a credit card.

What’s so great in this phrase? Clarity.

A good project manager intentionally limits the amount of information available to participants for discussion. The less information is provided, the lower the chance of an error.

If we look back at the above description, what’s in it for us in it? First, it helps us define the user. In our case, it’s a registered user who has previously placed an order on the website. Second, the required functionality should have time and data limitations. Third and very importantly, the action that the user performs is atomic. Sequences or non-linear sequences of actions indicated in the description of the functionality are the roads straight to hell. And for all the participants involved, not just for the customer!

Subjectively speaking, the ideal user stories imply that the user needs a minute or less to become aware of how to perform this or that action. In this case, by “aware” we mean that a user has already performed the same or very similar action in a different application.

Define Task Lists

What's next? Let’s break each of the functional descriptions into tasks and subtasks. It’s necessary to do this together with the developer who is expected to implement the selected functionality.

What is to be included in the task list? If the developer sees the task for the first time and has not touched it before, then make sure to include all of the actions that are required for the functionality to be implemented, including research and collaboration:

  1. Examine the documentation for integration with the payment gateway and payments with credit cards in particular;
  2. Coordinate the chosen method of integration and payments processing with your payment gateway experts/integrators;
  3. Agree with the project manager/tech lead on the chosen method of integration and transactions processing;
  4. Implement the storage and export of data needed to interact with a payment gateway (e.g., customer IDs, security keys);
  5. Implement the receipt and preparation of data for the order to be paid;
  6. Create a website form to allow the user to enter their credit card credentials;
  7. Implement data transfer to the order payment form on the website;
  8. Implement successful payment data receipt, processing, and storage;
  9. Implement error handling during the payment process;
  10. Implement the submission of payment receipt to the user;
  11. Implement messages/push notifications to notify the user of any error that has occurred during the payment processing.

After the list has been populated, ask your team lead/PM to put an estimate in man-hours next to each item’s description. Sum up the man-hours and assume that you can more or less rely on the estimated time you’ve projected. Why more or less? Because it’s impossible to plan everything, and there will always be bumps in the road to overcome. And the more detailed your task list, the fewer issues will occur, and the less extra time it will take to handle them.

As you complete the items in the task list, ask your team or tech lead to indicate the time actually spent on the task, so you will be able to assess the quality of your planning.

Project Planning Tools

Instead of using expensive or complicated and cumbersome tools, it's better to rely on your common sense and stick to simplicity.

For successful visualization of your project development processes, there are enough simple yet effective tools such as Trello or Github which let you leverage Agile project boards. Both tools let you arrange the descriptions of your solution’s functional features as cards, and attach a task to each of the cards with an indication of the estimated project execution time:

As a user, I want to pay for my order with a credit card - 30 hours

At the same time, nothing prevents the project manager from adding to the description the actual time spent. This can be done every evening, at the end of the working day:

As a user, I want to pay for my order with a credit card - 30h - 15h

This approach allows you to detect at an early stage if your development team lags behind the schedule and take reactive and proactive corrective actions (e.g. notify the customer of milestone delivery delays).

However, when we put tasks to the list, regardless of whether we use object-oriented or functional terminology, we still can’t know for sure how many code modules will have to be developed, deployed, or modified down the road.

What can work perfectly well here is dividing a user story into tasks, and then trying to draft modular tests for the classes or methods mentioned in the tasks. That’s an example from one of 8allocate’s real client cases (ICO platform development on blockchain):

As a system, I want to send the user’s personal data to the KYC service for verification.

And that’s how the task list for this work looks like:

  • Implement the receipt of personal user data from the local database;
  • Create a folder in the KYC service and add the user's personal data to the folder’s metadata;
  • Create a request in the KYC service to check and verify the folder’s data
  • Implement request information storage in the local database.

If your team works on the project development in two-week iterations, it can easily spend 1 or 2 days planning things. By “planning things” we don’t mean sitting in boring long-hour meetings with speculative reasoning and poker; by this, we mean writing tests and estimating functionality development and deployment time.

At first sight, it looks like win-win for everyone. We write code and do not waste time on collective reasoning. And we make estimates at least on the basis of the minimum amount of code, and an in-depth understanding of the customer’s requirements.

Since the first task of the above list has already been deployed and tested, let’s proceed to the second task and create a test draft for the method that uploads data to the KYC service:

Image title

Image title

Image title

The modular test of the second task decomposed into as many as 100 lines of code, and it took us about an hour to implement it. At the same time, the first five lines of code made us ponder over how we should implement the imitation of HTTP requests sent out. That’s when we remembered we’d already implemented some kind of a pseudo HTTP request that simulates the send-out of a POST request we need. Now when we have a test, did it become more clear how long it’ll take us to implement the required functionality?

In fact, it did. This task is very similar to the task of requesting data from the database, and we have already decided that one working day (8 hours) would be enough to implement a POST request send-out. And since we already have successful experience with a separate implementation of data processing rules within a request, we’ve decided to implement a new set of rules to be used for sending out POST requests.

The next two tasks from the list seem to be very similar so we can make the following estimations:

  • Implement the receipt of personal user data from the local database;
  • Create a folder in the KYC service and add user's personal data to the folder’s metadata – 8 hours;
  • Create a request in the KYC service to check and verify the folder’s data – 8 hours;
  • Implement request information storage in the local database – 8 hours.

Since other tasks in my list are of the same type (except that POST requests will contain binary data instead of JSON), we automatically assume we can realistically implement 3 user stories per a two-week iteration.

What methods do you use to estimate software development projects?

agile, estimation, project estimation, project estimation process, test driven development, tools and techniques

Published at DZone with permission of Edward Ossawa. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}