Analytics and task decomposition. How development time is determined
Hi all! Today I would like to talk about such a topic as estimation of development time. The topic is quite interesting. there is no generalized standard of assessment.
It used to be one of my first tasks at work, and when I was first given the requirements and said “Estimate how much time it takes.” Naturally, my first question was “How?”. At that time I could not even imagine how it is possible to evaluate what has not been done and it is not clear how it will be implemented …
What approaches are there and how can an analyst evaluate a task? I will try to answer this question further.
Grade Matrix
I just at that moment worked in a company that is engaged in custom development, and there a certain matrix was used for evaluation.
The matrix itself is a special file that lists typical tasks by difficulty levels and how much such a task takes the team’s time.
For example, to design a simple CRUD service without any special logic – 1 man-day for the analyst, 1 for the back, 0.5 for the front and 2 for the tester.
Or design a complex orchestration microservice with non-trivial logic – 4 days for an analyst, 5 days for development, and 10 days for a tester.
As a rule, these figures already include additional time for risks, possible integrations and various unforeseen situations.
To implement this approach and evaluate all types of tasks in advance, there must be a strong team with a sufficiently large accumulated development experience to:
– develop such an assessment template;
– successfully apply and evaluate against this template, bearing in mind that some tasks are not always easy to fit into a certain framework.
Subjective assessment
Subjective assessment of a specialist (whether an analyst or someone else).
Before the start of the release analytics, a customer comes to the team, brings some task statements (depending on the process, before such a task must be evaluated by a system analyst and other team members – it has already been decomposed and evaluated by a business analyst and an architect.
Next, the system analyst takes this statement – decomposes it – evaluates each decomposed story, subjectively estimating how long it will take him.
It all depends on the experience of the analyst, the number of similar tasks solved, and the accuracy of the initial statement of the problem by the customer. Further, based on the decomposition from the analyst, the rest of the team makes the assessment.
Grooming
A new process for me that takes place at my current place of work, and the meaning of which I liked.
Grooming itself takes place weekly:
The analyst brings his completed tasks there and presents them to the team, i.e. tells their meaning, demonstrates his technical task and explains his vision of solving this problem.
The rest of the team can express their comments (often very sensible, and this helps to find some flaws or even logical holes in your TOR) and share their opinion on the task, offer their own solutions.
An analyst in the process of grooming can edit the TOR, if it does not take much time, and such an “extreme analytics” is obtained in an online format.
After all questions/suggestions are over,
the assessment of the task by the development and testing team begins, already according to the written TOR, which significantly increases the accuracy of the assessment than if the tasks are evaluated according to a preliminary mini-analysis.
