Simple time use forecasting practices
The ability to qualitatively assess development time costs is one of the key skills of a good development manager. Erroneous predictions of deadlines for completing tasks, as my personal experience shows, is one of the if not the main sources of pain for managers, it is very large-scale.
Practices that allow us not to rely on luck in this matter and try to guess the time required to implement an idea in the code are simple and accessible to everyone. Planning is quite an ordinary job, and doing it requires well-defined actions.
Formulate functional descriptions
The basis of good planning, well-formulated description of the functionality that needs to be implemented. The best way in my opinion is a rather long-thought out format for user stories or behavior patterns (use cases):
As a user, I want to pay for an order with a plastic card
What good is this wording? Clarity. A good manager consciously limits the amount of information available to participants for discussion. The less information, the less likelihood of an error.
What do we have here? Firstly, the user of the implemented functionality is clearly indicated - a registered user who has already placed an order earlier. Secondly, the required functionality is quite clearly limited in the amount of data used and in time. Thirdly, the action performed by the consumer is atomically. The last moment is very important. Sequences or God forbid nonlinear sequences of actions indicated in the description of functionality - this is the road straight to hell. And for all participants in the process.
Subjectively, I deduced for myself that the ideal language seems to be implying that the consumer is doing something that does not require more than a minute or a couple of minutes of time for an informed user. In this case, an informed user considers such a user who performs the indicated action for the first time in our application, but has previously performed similar actions by some other means or in other applications.
Define task lists
What's next? Further it is necessary to break each of the functional descriptions into tasks. It is necessary to do this together with the developer, who is expected to implement the selected functionality. What to include in the task list? If the developer sees the task for the first time and has not touched it before, then literally all the actions that are supposed to be required, including research and collaboration:
- Examine the documentation for the integration with the payment gateway regarding the part of payments with plastic cards
- Coordinate with the payment gateway experts the chosen method of connection and making payments
- Agree with the project manager on the chosen method of connection and making payments
- Implement storing and retrieving data necessary for interacting with a payment gateway (customer IDs, security keys)
- Implement receipt and preparation of order data to be paid.
- Develop (connect provided by the payment gateway) form for entering plastic card data by the user
- Implement the transfer of data on the order and its value in the form of payment
- Implement the receipt, processing and saving of data on successful payment
- Implement error handling during the payment process
- Implement the mapping of payment receipt to the user
- Implement the user to display error messages that occurred during the payment
The more detailed the list, the closer to reality will be the estimate of development time. After the list is ready, ask the developer to put an estimate at the end of the description of each of the items in the working hours. Sum up the clock and assume that you can orient yourself around the time you have. Why am I talking about? Because plans never stand the meeting of reality. It is impossible to plan everything, and surprises almost always come up during work. And the more detailed your task list is, the fewer surprises can occur, and the less extra time it will take to deal with these surprises.
As you complete the items in the task list, ask the developer to indicate the time actually spent on the task, so you will be able to assess the quality of your planning.
Instruments
I am not a supporter of expensive or not very clear planning tools, with poker, combustion charts and story points. I think management should rely on common sense and the principle of maintaining simplicity.
For successful visualization of the development process management, there are enough trivial tools, such as Trelo or Github project boards . Both here and there the descriptions of the functionality can be arranged in the form of cards in lists, and a list of tasks can be attached to each of the cards with an indication of the forecast for the execution time simply as a number after a dash at the end of the description:
As a user, I want to pay for an order with a plastic card - 30 hours
At the same time, nothing prevents the project manager from adding to the description the actual time spent. This can be done every evening, at the end of the working day:
As a user, I want to pay for an order with a plastic card - 30h - 15h
Lagging behind the schedule can be detected at sufficiently early stages of work, discuss the current situation with the developer and take corrective actions and, as a minimum, notify the customer about a possible lag and its causes, which are quite often quite objective.