How to correctly evaluate project terms using the example of a web studio

What is the difficulty

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

• Software development is a process of intellectual activity. There are typical tasks that have already been done before, to evaluate such is not difficult. But there are also non-standard tasks. We usually have 20-30% of the project work. These tasks cannot be evaluated, because it is not known how long they will take and what problems may arise in their development. A simple example: try to answer the question: “How long will it take to get from Zapolitsy to Moscow by bus? And how much does such a trip cost? ”. It’s unlikely that you have been there before, so this task is non-standard for you, and you won’t tell how much. With an example it’s simple - I called the bus station, found out the price and duration of the trip. But even here there is a risk of being stuck in traffic. And the customer will call you and shake the result. And he’ll do it right: promised - do it.
• 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 complete the task many times faster than a beginner.

I wrote these three reasons in descending order of their problematic nature.

How do we fix them?

I'll start with the simplest one - the qualifications of the developers. It is decided in this way: either middle-skilled developers go to the project team, or we put a novice and a professional on the same team so that he pulls up the novice in weak places. Thus, the speed is averaged to the speed of the average developer and the role of qualification for a period of 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.

It is easier with a non-scramble: requirements are collected from the customer, a statement of work and an estimate are made, and work begins strictly according to the statement of work. We use this approach when developing simple projects: landing pages, corporate sites.

But everything in TK cannot be described, therefore, controversial issues always arise 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. I don’t want to spoil relations with the customer, so I have to either spend the time of the manager discussing this problem, or spend the time of the programmer to solve the problem, or spend the time of the manager + the time of the programmer to come up with an alternative task and its solution. In this case, we usually choose the option that will bring the greatest benefit to the customer’s business (because “Wishlist” often have no serious justification, and sometimes even harm).

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

How is scrum done?

A large list of tasks is compiled for the project - the backlog. It is sorted by priority, as the customer wants. The team is gaining 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 the most interesting thing is that if something changes for the customer over these two weeks, then he can calmly throw out one of the tasks in the project. Or put a new one. Or change the priority. Thus, in the next two weeks in work will be what the customer wanted. This is what flexibility is all about. 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 trello.



And the team’s work is organized in youtrack.



Thus, you can not lay down time for changes in risks and painlessly introduce new requirements into the project, 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, we evaluate standard tasks using the same technique. What I will describe is part of scaram, poker scoring. Tasks are taken in turn 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. Estimated 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 whose rating is higher than 21 are necessarily broken down to avoid a rough estimate.

The evaluation process itself goes like this: the first one who directly implements this task says: did we do it or not, how it will be programmed, where problems may arise, with what probability they will arise - all that can help in assessing the complexity of the task. Then the rest speak out, 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 ratings.

Thus, no one knows someone else's solution. If all ratings converge, then the vote ends and the task is assigned the corresponding difficulty, but if at least one of the participants has a different rating, the discussion continues. Everyone must defend their opinion.

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