For a software consulting firm like bitcrowd, it is crucial to estimate the effort of the work ahead. One main reason is risk management: underestimating a task or a project requires us to absorb the extra cost. But it is not only beneficial for us! An effort estimate can help our clients plan their product roadmap accurately based on our implementation timeline. They can also prioritise their features efficiently based on the ratio of effort to product value.
In this blogpost we will explore our best practices regarding requirements engineering & estimations.
Requirements engineering
This first step is by far the most arduous, as it requires to gather and describe the essential aspects of a feature or a product. Our team of engineers has to take a deep dive into an existing codebase, or imagine how a new one could look like.
From business needs to specifications
In this process, it can be useful to help the client formulate business needs, as the specifications (whether in design or development) should derive from them - not the other way around. In other words, what is the use case behind a feature, what problem does it solve? As opposed to: how is the feature implemented, how does the page look?
Consider these two requirements:
- On the accounts index view, the user should be able to see the timestamp of the account's last login
- The user should be able to easily identify stale accounts
The first one already locks the reader into a technical solution. It does not say what the user should make of this timestamp information.
The second one expresses a need. It makes no implication on how the system functions. This gives much more freedom to the engineer on the solution, and they can derive a technical specification from it in way that fits the model and the client. It also provides a simple way to assess, retroactively: are we solving the given problem with our solution?
Data model
Building a data model, even as a draft, can be a great tool and visual support during the requirements engineering process. It is an excellent way to:
- identify corners of the product that could otherwise easily be missed
- discuss the implementation strategy with the team
- already define the domain and main components of the application
- pin vocabulary words (like a resource name) that everyone in the team can then use, and understand their relationship to the product
Estimations
Estimating a project just after reading a client's proposal is extremely hard. This exercise only becomes manageable after two (or more) engineers transformed the business needs into specifications, and broke down those requirements into pieces small enough that a developer can tell “this would take an average developer XX days”.
Enter the Mindmap
Most of the time, text formats are a very poor fit for describing technical specifications. A text document is structured from top to bottom and fails to visually transcribe how our codebases and how our web products are just good old graphs. The web is still essentially file navigation, like our code repositories.
Additionally, text can imply a hierarchy between sections, while in a graph, the order of the nodes at the same level is irrelevant. This can encourage an engineer to design features in isolation, already predicting an implementation roadmap that can be parallelized.
A mindmap is an excellent tool to visually support the task at hand, since it is well-equipped for exploration, re-structuring, moving sub-graphs into another area. Its visual framework gives clear encapsulation boundaries and shows the dependency between a parent node and its children.
The capacity to easily collapse and expand entire sections of the graph also allows to visualize the requirements at different levels of detail.
New codebase? Don't forget non-feature specs
When estimating a new project, one should not forget to note down in the mindmap some essentials of a new codebase. For example: initial repository setup (and sometimes, running generators), linters, CI/CD pipelines, error tracking etc. And additionally on the application level: i18n, layout styles, navigation and so on.
To the numbers
Going back to our previous example:
Business need
The user should be able to easily identify stale accounts
Specification
On the accounts index view, the user should be able to see and sort by the timestamp of the account's last login.
Estimation
Here the developer would need to consider what steps are necessary to achieve this task. We need a database migration to store the last login timestamp, we need to record this timestamp on a successful login, and we need to update the accounts index view to show this timestamp, and sort by it. These steps have most likely been done hundreds of time by an average backend developer. They are familiar and graspable. The levels of uncertainty & complexity is quite low.
The effort might be affected by the quality of the codebase, whether it is well structured and well tested, whether the developers are familiar with the codebase, whether reusable components already exist etc. The effort should also account for review cycles and QA.
And then?
What is important here is that we are not asking the developers to commit to this number. We are asking them to make an estimation based on what is currently known for the project, and on tasks that were broken down enough that they can comprehend them fully. The variability of estimations can be alleviated by involving two or more developers, preferably with different experience levels or domain knowledge.
The mindmap allows us to rollup the days up to the central node and get a number of days. Again, if the result is 102 days, we are not signing off on that exact number, but can then tell if the project will take 2 weeks, 2 months, a year, and where complexity lies. Of course, the smaller the scope, the more precise the estimation can be. We use the same technique for clients coming up with a brand new product idea, as for clients asking for a new feature.