Estimation process in outsourced teams
This article is going to kick off series of posts on estimations in outsourced teams based on my experience working in software development with Flatstack. The goal is to create more transparency regarding remote teams and approaches that are employed.
As part of this article, I’d like to review estimation processes for development based on client’s business maturity and briefly touch base on agile software development methods.
Within my practice, estimations is a process where developers based on their expertise level rate each given task in terms of difficulty points. We do it in a form of Planning Poker until we reached a consensus on a final estimate (check out this sweet app). Then based on historical data like velocity, those points are “translated” in a rough equivalent of time frame that will be needed for requirements completion.
To unwrap this term — “estimations”, let’s take a look at the process that we followed in our largest team working on an enterprise sized client for estimating big epics (1–3 months of development efforts):
- Requirements for implementation are submitted to a development team.
- Preliminary investigation is done to address “blanks” or overlooked scenarios — so called Q&A session.
- Inception meeting with all stakeholders involved is organised in order to discuss business value that the feature is to bring to the company, objectives that are set and “must haves” for implementation.
- Post-inception report specifying any areas of the existing system that could be impacted is prepared.
- Post-inception report is sent over to the technical contact/manager on the client side for review (to ensure everybody are on the same page and nothing got missed).
- Feature break down is done.
- Tasks that have been created are being reviewed by technical contact/manager on the client side (for final approval).
- Estimation session is run within the team and tasks are given difficulty points (via Planning Poker).
- Based on historical data of team’s velocity (points delivered), rough delivery date is announced.
You might wonder — why are there so many stages: pre-inception, inception, post-inception? The reasoning for that is to effectively use the time of all stakeholders involved. Instead of day-long inception meetings, we let team leads analyse the documentation for any missed bits of information. At the same time the rest of the team is focused on development of current priorities that are in “Work In Progress” (WIP) status.
When all details have been received, we schedule a call with clients and a whole team on our side. A day or so before the inception call, everybody in the team skims through the specs to familiarise with the goals and give it additional thought. Therefore, as everybody is prepared in advance, our virtual inception meetings end up being maximum 1h long. The final step is the post-inception report preparation that provides technical insights. Also it allows experts on both sides to cooperate and come up with the most optimal solution.
As a result of the described process, everyone participates to the maximum of their expertise level:
a) our clients can concentrate on strategic goals,
b) team leads add value by preparing all assets for further development (technical leadership),
* Note: they work more effectively as technical nuances are discussed within engineering groups.
c) the rest of the team continues to bring value by delivering current priorities.
Тhat process works for our needs, but it might be lengthy and exaggerated for other projects. In fact, you can easily shorten it down! Quite often some of the steps could be omitted, this is especially true based on the business maturity of the client:
- Startups usually have a more compressed workflow when it comes to estimations — steps 3, 4, 5 and 7 are skipped. The reasons for bypassing/minimising time for preparatory phases are:
1) startups are more limited in terms of budget,
2) additional information is often being discovered down the road and acceptance criteria are adjusted accordingly. - Enterprise size companies on the contrary have a more detailed and expanded workflow when it comes to requirements, as more risks are associated with changes to the system. There are additional check-points before development kick-off: steps 5 and 7 described above. On top of that, during tasks implementation there is an in-house review and QA from the client side involved. The priority is not to complete the requirements on budget, but to deliver high quality results ensuring data integrity, security and accessibility. Even before preparatory stages on our side there are extra steps involved from the client side, too; e.g. marketing research, theory testing, design team working on UI&UX components of a new feature (mock-ups, descriptions, use-case scenarios etc.), prioritisation of epics done by R&D departments, etc. Only after all that preliminary work the specs are sent over to remote teams.
Regardless of the stage your business is at, software development is cool in a way that there are already methods tested with time for you to select.
For startups you might want to consider SCRUM agile software development method as it provides maximum flexibility and is perfect for frequently changing requirements.
For production support projects you might want to consider Kanban that promotes improvements to the existing system and strives to eliminate resistance to change. This is done by aiming to minimise overhead, use visualisation and having continuous flow.
For mature companies and enterprises you might want to consider a mix of SCRUM and Kanban, where you can enjoy the adaptivity to changing environment and focus on processes perfection — Scrumban.
There are also other software development practices that you can employ, each of them has its pros and cons depending on your goals. In general — research, experiment and improve processes if needed. This way you’ll be able to introduce approaches that are most beneficial for your projects.
In the next article within this series we’ll be taking a closer look at causations of inaccurate estimations with reflection to cases from my experience. Stay tuned!
If you find this post useful please click the 💚 below and be sure to follow me for more articles on software project management!
Check out my previous articles:
