Previous chapter:
Next chapter:
So, you gathered all the required input to finally design and estimate your software project. How to create an actual solution?
Things to Estimate
You can't estimate any system without any sort of a breakdown. Below you will find the breakdown I typically use.
Building Blocks
First step is to identify the building blocks the solution will consist of from a high level. There are different techniques to do that:
- Event Storming
- Action/Actor approach
- Workflow approach
Whatever you would use you need to understand pieces of the system you design: what will be the user facing components, where your business logic will reside, where you store the data, and which components are talking to which.
Let's recall some of the stories we were working with in the previous chapter:
Example: the user can login into a mobile bank with login and password(story 1). The user can see the list of the accounts(story 2). The user can see the list of transactions for the period of time(story 3). The user can make a money transfer to the user of the same bank by the phone number(story 4).
The result I draft in several minutes may look like this:
You may have tons of questions right away, like why would you have two databases and microservices, what is the Banking Engine and where it come from and so on. I would like not to discuss the solution in this article: it's irrelevant for the estimation itself. Whatever the decisions have been made, an architect created a design and we have components.
Quality Assurance
Although the design is not thought in details, it is already good enough for the estimation.
Now you need to estimate is the effort to be actually sure the system will fulfill the requirements correctly. Typical questions are:
- How much of automation testing we will use?
- Do we need contract testing?
- What tools will be used for the performance testing?
- How do we test on security?
- How do we measure availability(nines)?
QA can have a significant part of the budget and you can't really do a production system without it.
Estimations
Base Estimations
Ok, now it's time to convert our components development and other work into work streams we can actually estimate.
As mentioned earlier, the architect does not typically do the estimations by himself/herself. The technology experts or application architects usually do that.
Then those people proceed to estimate their components. How do they do it? They break down the work for the component into small pieces. Those pieces are picked in a way that the estimation is more or less clear. Say, for an Android developer it's clear how much time it takes to create a screen with a couple of buttons. At the same time a backend developer understands how many days are required to create an API call, wire it up to the database etc.
Also, we need not to forget about technical setup. In case of greenfield development, we need to setup the git repos, create a project skeleton, set the initial app architecture etc.
Another thing you might want to thing about is the User Experience Design. Once you have a website or a mobile app, it should be estimated as well. Again, don't do that yourself: get a designer to do the estimation.
Once technical stuff is accounted for, we can now lay down our User Stories on top of the components in order to understand how much work should be done in each component. It can look like this:
There are different estimation techniques to do so: PERT(also known as 3 point estimate), optimistic/most likely, optimistic/risk and so on. Pick the one you fill the most comfortable with!
The question is: do you include code review in the estimation? Do you include unit tests? What about other testing?
My approach is to estimate pure development effort. The reason for that is you can add almost everything else using buffers and multipliers. And here's how.
Multipliers
Here's what you need to account for. I will give you typical values which you are free to alter for your project.
- Code review - 10%
- Bug Fix - 30%
- Unit Tests - 25%
- Documentation - 5%
- Functional Testing - 30%
You can also add some risk buffers, but I would like to talk about risks in a separate chapter.
Timeline
In order to understand the timeline you have to understand the sequence of actions which are required to complete the project. You should carefully understand how the project activities will happen.
Discovery
Discovery is a separate activity, which should be conducted in order to get more details on the product. During this time a small team gets to know the IT landscape, clarify the requirements, establish the necessary connections to the stakeholders. This activity is also design to unblock the future construction work: get the accesses, understand the release procedures, staff the project etc. Discovery most likely takes from a week to a month depending on a project size and require a Solution Architect, Project Manager, QA lead and a Product Manager at least.
Construction
Once the requirements are clear and teams are ready to go, the construction phase begins. You need to understand the sequence of user stories you are going to build. This is similar to project schedule, which you can build using Gantt Chart.
Now you need to understand the Critical Chain for your project. If it doesn't sound familiar, I made a review of the book called the same way. In a nutshell Critical Chain is similar to Critical Path approach, however it accounts for the resources which are a constraint to the system.
UAT
Don't forget about User Acceptance Testing period. Allocate a week or two depending on the project size.
Summary
At the same time you have estimation numbers split by components. Usually you have a team per each component or a set of cross-functional teams for the whole solution. One way or another you still need people. Make a table with all the roles you need for the project and estimate for how long you need a particular person. Following our mobile banking example we can have the following:
Having those days you can create a full resources document with the week allocation, cost calculation etc.
Next steps
That's it for today! In the next chapter I will be covering the resource allocation, cost calculations and the estimation template document. If you need a personal consultation on the estimating the project or solution architecture I am available for it.
Don't forget to smile alright! 🤩
Also, if you liked the article, don't forget to Subscribe to get notified once a new article is published. Sharing the article in your social networks are always welcome as well.