Quick and Easy Initial Effort Estimate for Software Projects

So you’ve received a software development project? How do you determine a kickoff estimate to make it happen?

While working in software development at Plexteq for the past several years, and having delivered over one million man-hours, we have developed techniques that deliver reasonable effort estimates with a clear and transparent methodology. In this article, I am going to share what we have learned through our experience.

Problem

Let’s consider a proof-of-concept (POC) estimation at the pre-sales stage. The risk of project failure at this stage is higher because:

• There is greater uncertainty about the business requirements of project stakeholders.
• Specific features and details are not yet known.
• The environment is fast-paced and products must move swiftly to market.

Put simply, actors must advance even before their directions and directives are fully realized.

Agile methodologies do their job fairly well, and a POC execution might be streamlined using Scrum at some point. At the estimate (ETA) preparation stage, this is irrelevant. All stakeholders can find themselves in trouble, and so they must appreciate the complexity of the project and enjoy an ETA that conveys the worth of their product.

The situation is even worse in the absence of standardized methodologies for evaluating the ETA. Allow us, then, to propose a successfully and consistently applied in-house solution.

Solution

While the ETA preparation venture seems daunting, let’s be constructive and proceed by determining what we have available at this early POC stage, including, in most cases:

• Business owner representative (a good source of high-level requirements).
• Engineering team (the ones who will be implementing the POC).
• List of features.
• Budget estimate.

That’s already something!

We have seen many cases when, at this point in the process, the engineering team remains one-to-one with the business owner representative while diving deeply into low-level product details and technical stack-selection burden. For our purposes, this is counterproductive and threatens POC execution.

To avoid such an outcome, we recommend focusing on two things:

• Build a business domain model before development begins.
• Plan features/user stories with high-level granularity.

In our opinion, business domain modeling is a must. The team must speak a business language that is clear for all stakeholders to understand. The best place to start is with a UML use-case diagram. This diagram is simple and clear, even for non-engineering team members. Let’s see how this works with a real-world example.

Analyze

Imagine developing a mobile application with the following requirements:

• An iOS application to assist in posting text, photos, and videos for lazy users over various social networks (Twitter, Facebook, Instagram, Snapchat, etc.) with a single click.
• A server-side for storing authentication data and user-linked accounts.
• A back-office system for accessing user data and overseeing system operation.

This is what one would likely get from a business stakeholder, as opposed to the complete log, divided into functional and non-functional requirements, as developers often expect.

As mentioned above, the first step is to build a business language rather than to dive deeply into low-level product details. We must devise and adopt a common language to communicate with all parties involved in project discussions, including, but not limited to, business owners, project managers, engineers, finance officers, and administrative personnel.

For a technical system, the best way to accomplish this is with a UML use-case diagram that denotes individuals’ roles and functions. Such diagrams are a powerful yet underused and undervalued means of tackling these problems in the software engineering world.

Model

Every use-case diagram starts with role definitions. Here, we have two of them: iOS application user and back-office administrator.

There will be multiple users using the system, and each one must be able to perform the following high-level actions:

• Log in to the application – This function enables a user to register or authorize within our system from the iOS application.
• Log in to the external system – The external system is the target system users will be posting to (e.g., Twitter, Instagram, and others supported by the app). The iOS user must log in from our app, so it can obtain security tokens to post on their behalf.
• Log out from the application – The iOS user must log out of the application to log in with different credentials.
• Log out from the external system – The iOS user must detach the external system from their account (i.e., users must decide to stop using Instagram from the app).
• Post message – The point here is for the iOS app to post a message to an external system (e.g., Twitter) on behalf of the user.

The high-level actions for a back-office administrator include:

• Log in to back office – A back-office administrator must be able to perform administrative actions within our back-office system.
• View list of users – An administrator must be able to oversee registered users.
• View actions per user – An administrator must be able to pick up a specific user and see what actions they have performed and when.
• Block user – An administrator must be able to restrict a specific user from logging in.
• Log out from back office – For security reasons, the back-office administrator must be able to completely log out of the application.

For the sake of simplicity, let’s focus on the role of the iOS user and assess its core functionality from the list of requirements. By this point, we assume that the core business language is complete, in that we know who is involved and what they are doing. High-level functions are clear, and we can consider the details. Specifically, now is the time to determine:

• What kind of messages could be posted?
• What external systems are allowed.

Following a discussion with business stakeholders, we discern that text, photo, and video are the three types of messages allowed. Let’s consider this in light of the UML “extension” relation.

To make the picture complete, we must demonstrate that each type of post is supported by our external system.

Now we are all set with use-case modeling for the iOS user role, and we also know what independent modules the engineering team will implement.

Deliverables Analysis

Once functions/use cases are clear, we can focus on specifying the expected deliverables. For our application, the stakeholders have confirmed the following:

• Front end – This is the iOS application itself.
• Back end – This is the server-side part that’s responsible for user sign-up, log-in, and interactions with supported external systems such as Twitter.
• Documentation – This is documentation that the engineering team prepares during the implementation phase. Let’s assume the stakeholders agreed that this deliverable would be lightweight and narrow down to back-end API specification. This determines how the iOS application interacts with the back end.

Let’s assign each deliverable a letter: B for back end, F for front end, and D for documentation. Now we will ask our engineering team to go through the UML use-case diagram and mark every use case with a deliverable marker, adding the appropriate letter relating to that deliverable.

Here is an example of how this might be done:

This important step allows the team as well as business stakeholders to understand the distribution of effort across the features, thereby enabling estimate calculation in the next step.

Estimate

The most exciting part now comes into play – let’s get an estimate done!

Here, we must introduce use-case complexity grades, facilitating distinctions regarding use-case complexity without going too deep into the details. Each grade should have a name, color, and a single letter. Let’s consider a simple three-level grade:

• A low complexityuse case is easy to implement, doesn’t intersect with other use cases, doesn’t have severe dependencies, and can be implemented by a single engineer.
  • Color: green
  • Symbol: L
• A medium complexityuse case is of moderate complexity, requires infrastructure work that will be further re-used by other engineers, and takes significantly longer to implement than do low complexity tasks.
  • Color: yellow
  • Symbol: M
• A high complexityuse case involves multiple dependencies with other use cases/modules, requires major infrastructure work, and takes significant time to implement.
  • Color: red
  • Symbol: H

Now let’s ask the engineering team to distribute all use cases between the complexity grades so that the average complexity is equal within each group.

After distribution is complete, the engineers can provide raw effort estimates per complexity grade. Let’s assume the team came up with the following figures:

• Low complexity (L, green) – 1 week
• Medium complexity (M, yellow) – 2 weeks
• High complexity (H, red) – 3 weeks

The use-case diagram should then be adjusted to portray use cases with colors reflecting their level of complexity, as the diagram below demonstrates.

At this point, and if the team feels the execution is connected with specific risks (e.g., the human factor, lack of knowledge in a certain domain, or high complexity), they can provide risk buffers to individual tasks.

In our case, the team has asked to add a 30% risk buffer to “post message” and “log in to external system” realizing that things could get more complex during implementation.

Once the risks are added, we can calculate the result. Here’s a brief summary of what we have:

• 3 use cases of high complexity (H), 2 of which have 30% risk buffers.
• 4 use cases of medium complexity (M).
• 16 use cases of low complexity (L).

By adding up weeks depending on task complexity, we get an estimate of 35 weeks. This is represented as:

ETA = (3*3 + 3*0.3 + 3*0.3) + (4 * 2) + (16 * 1) = ~ 35 w

Which is to say: approximately three months for a team of three engineers.

Now we are done and can have fun with detailed project planning, using Gannt and PERT to plan project execution and duration.

Conclusion

We’ve described a technique for quickly and easily providing an ETA for software development projects at an early, pre-development stage. At Plexteq, we have used this approach for a number of years and always get relevant and precise outcomes.

Such an approach benefits all parties because the team builds and uses a business language and domain model throughout the project execution. Furthermore, the team can avoid diving deep into low-level technical details, allowing it to focus on core features. Finally, the team is responsible for defining complexity grades and eventually estimating use cases, motivating members to accomplish these goals within the estimated timeframe.

Once the effort estimate is calculated, the project management team can formalize this ETA into a Gantt/PERT approach, scrutinize use cases, and incorporate the project into any Agile software development methodology.

Happy estimating!

Further Reading

Stop Estimating: The #NoEstimates Movement in Agile