How to estimate the timing of the project on the example of a web studio

What is the difficulty

It is a reasonable situation when the customer wants to get an accurate assessment of the project in terms of time and cost. The cost depends on the timing, so let's decide why it is difficult to estimate the timing in an IT project:

• Program development is a process of intellectual activity. There are typical tasks that have already been done before, it is not difficult to evaluate such. But there are also non-standard tasks. We usually have 20-30% of the project work. These tasks cannot be estimated, because it is not known how long they will take time and what problems may arise during their development. A simple example: try to answer the question: “How long does it take to get from Zapolitsy to Moscow by bus? And how much does such a trip cost? ” It is unlikely that you have ever been there before, so for you this task is non-standard, and you can’t tell right away how much. With an example, I simply called the bus station, found out the price and duration of the trip. But even here there is a risk of getting stuck in traffic. And the customer will call you and shake the result. And rightly so: promised - follow.
• Customer requirements. In almost any project, the initial requirements are changed during implementation. The customer could forget something or new Wishlist appeared after the start of the project.
• Another problem arising from the fact that intellectual activity is the qualification of the developer. A professional can perform a task many times faster than a beginner.

These three reasons I wrote in descending order of their problematic.


')

How do we eliminate them

I'll start with the simplest - the qualifications of developers. It is solved this way: either developers of medium qualification go to the project team, or we put a novice and a professional in one team so that he pulls a beginner in weak places. Thus, the speed is averaged up to the speed of the average developer and the role of qualifications for the time drops significantly.

The following two problems are more serious. I'll start with the second - changing customer requirements.
We use two options for building development processes: Scrum and HEScrum.

Neskram is simpler: requirements are collected from a customer, TK and budget are compiled, and work begins strictly on TK. This approach is used in the development of simple projects: landings, corporate sites.

But it is impossible to describe everything in the ToR, therefore controversial issues are always formed during the project. For example, this happens where the customer expected something de facto, but for us it is a difficult (or long) task and it takes time. You don’t want to spoil relations with the customer, so you have to either spend the manager’s time discussing this problem, or spend the programmer’s time to solve the problem, or the manager’s time + programmer’s time to invent an alternative task and solve it. In this case, we usually choose the option that will bring the greatest benefit to the customer's business (after all, the Wishlist often does not have a serious justification, and, sometimes, even harm).

In large projects, such situations arise inevitably. And this time is laid as a risk. Yes, let it not shock you, so do all the studios, they put a certain amount of time at risk for which you overpay. So do many companies that work with great uncertainty in projects.

How is it done in a scram?

For the project is a large list of tasks - backlog. It is sorted by priority, as the customer wants. The team recruits tasks from this list for 2 weeks of work. After two weeks, the customer receives a fully prepared and tested part of the functionality. But what is most interesting, if during the two weeks something at the customer changes, he can safely throw out some of the tasks in the project. Or put a new one. Or change the priority. Thus, in the next two weeks, the work will be what the customer wanted. This is the flexibility. There is one BUT: the customer cannot change, remove or add tasks to those already in work, i.e. in these two weeks.

Work with the customer is organized in trillo.



And the work of the team is organized in youtrack.



Thus, it is possible not to lay the time for changes in risks and to bring new requirements to the project without serious consequences, which is beneficial both for us and for the customer.

The last problem is the estimation of the duration of non-standard tasks. By the way, standard tasks are evaluated using the same methodology. What I am going to describe is part of scaram, evaluation by poker planning. Tasks in turn are taken from the Backlog. The assessment is carried out by the entire project team, whose members (attention!) Must come to a single decision. If at least one of them disagrees, the discussion of the problem will continue. Evaluated in arbitrary units, we call them story points (sp). These conventional units are part of the Fibonacci sequence: 0,1,2,3,5,8,13,21. Tasks that have a score above 21 are necessarily split to avoid a rough estimate.

The evaluation process itself goes like this: the first is the one who directly implements this task: whether we did it or not, how it will be programmed, where problems may arise, what probability they will arise - everything that can help in assessing the complexity of the task. Then speak the rest, ask questions. Each has 8 cards with Fibonacci numbers 0,1,2,3,5,8,13,21 (a special deck of cards is used). When everyone is ready to vote, everyone puts one card face down. When all the cards are laid out, they turn over, and everyone sees the estimates.

Thus, no one knows someone else's decision. If all the assessments converge, the voting ends and the task is assigned the appropriate complexity, but if at least one of the participants has a different assessment, the discussion continues. Everyone must defend their opinion.

As a result, we have a flexible team that can adapt to changing customer requirements and is able to accurately predict the timing of projects.