Some time ago I wrote about estimations and how to calculate the effort of the tasks in an attempt to facilitate the process of thinking and reasoning to transfer effort to time, not to impose a new scheme or format.
Interesting enough one of the comments I received was:
It does not make sense, I think the time and I multiply it by 6 and that's it.
Curiously, there is a lot of uncertainty in this method of calculating effort or time; it makes me wonder how customers can accept that method. But then again, these are estimations and it is valid if that is your particular way of working. As an alternative, I would like to focus on what does each task that I estimate have to do with other tasks, other chores, other best practices and whatever my experience reminds me to be aware of in such task.
If you use the Agile methodology, you will be familiar with the following development lifecycle:
- Plan
- Design
- Build
- Test
- Review
So I would like to ask:
Why is there so much variation between the estimated and the real times?
I think that the reason can be a simple one: because when thinking about a task, developers are ignoring all the necessary processes that the end product will have; it is there where they are seriously failing in the estimations since, when being questioned by the necessary effort of a specific task, they focus only on the construction phase:
I think it will take me about 3 hours to finish this ... I would say that 1 point of effort.
PERFECT!!! but ...
- What about the time required to understand the task? investigate or plan the architecture of it?
- Or the necessary to follow the good practice of testing first then coding?
- And the time needed for Quality Assurance, and I am not referring to manual testing, but to the revision and refactoring of the code?
- There's a need to release the code under certain process, how much time will this take?
Although each project will have its processes and its definition of done very clear, we must not forget the foundation of the system development, not for nothing, there are so many different models that we can adopt and adapt according to our needs.
At Magmalabs, and without going into too much detail, the life cycle of a task is more or less as follows:
-
Task Analysis: [QA & Developer]
Both developer and QA, work together on reviewing the current requirements of the task in order to define the Happy Path and Alternate Path testing scenarios; this process helps on defining the architecture of the application and ensuring the minimal test cases covered.
This also helps on one of the weaknesses of Agile Methodology: Documentation.
By having QA creating and maintaining a document with the scenarios, we are ensuring the understanding of the whole project for everyone involved with it, call it Product Manager, Owner, Stakeholder or even a whole new development team.
-
Task Development: [Developer]
This is the interesting part for any developer: the current development of the task.
By following the best practice of BDD / TDD, the developer starts by writing the scenarios that he and QA previously defined and then doing the implementation of the current feature. It's important to note that, as part of Quality Assurance, you need to invest time in evaluating and refactoring your own code before ever sending it to review.
Once finished, the developer should create a well defined and structured Pull Request by adding at least:
- Relation to the task
- Description of the objective of the PR
- Changelog
-
Code Review: [QA, Devs, Architect]
Having the PR created:
- QA will be in charge of ensuring the tests were written.
- Other developers or architect will review the code implementation
It's important to consider the time required for review; if you follow good processes and practices, you must know that every day every developer must spend time performing code review to make sure no code lasts more than one day without being reviewed by QA on a proper environment.
-
Stage Release: [Dev]
Having tests passed, code updated (if needed) and approved, it's time to release the code to QA / Stage environment for manual testing. The time involved in this will surely vary from project to project depending on the level of automation you have, the configuration and infrastructure of the project, and the processes followed by the team.
-
Manual Testing: [QA]
Yaayy !! This is for QA team what Task Development is for the Developers: manual testing of the feature implemented.
It is supposed that development work already ended and the time spent by QA doing manual testing is not considered as work from the developer but of the task itself, and it is it is important to have this time in mind too.
As you see, it's not only about coding but also the whole process of delivering a feature; all the development lifecycle is involved at task level. Right now all our estimations for all tasks consider these processes, and with all of these guidelines, we can follow the estimations reference from How Accurate Are Your Estimations.
Again, what I present is not the holy grail of the methods to generate infallible estimates, however, and speaking from experience, I have witnessed improvements in the certainty of task estimates, which translates into better planning, greater clarity of the project status and better quality of customer service.
Looking back on the comment, who knows, maybe multiplying the time by 6 was intended to include all these processes.
Thank you for reading. Please leave a comment if you want me to continue exploring topics like this one.