Problems with the preparation of estimeytov for tasks? Use the two-day method.
The biggest problem in the software development industry is the inability to predict the completion time of tasks with a sufficiently high accuracy. Very often - this is due to the fact that developers allow themselves to give groundless assumptions about the completion time for sufficiently large or uncertain tasks.
Take for example the situation when we talk about the difference between the implementation time of 1 hour and 2 hour tasks. It is quite easy for us to operate with similar figures and explain why the execution of one task will take an hour more time to complete. But when it comes to the difference between the 34-hour and 35-hour tasks, the rationale for such a one-hour difference looks completely incredible. Actually such a comparison shows that the best estimeyty depend on the size of the estimated tasks .
So we came to the conclusion that our story (User Story) should be divided into small parts (the smaller the part, the greater the accuracy of the estimates). How small should these pieces be? The answer to this question lies in the name of the two-day method.
')
Probably the best thing about this method is that there is only one rule in it - break your user story into parts not exceeding 2 days in implementation time.
This simple method will also lead to the emergence of many, not quite obvious, but good and useful habits:
- Contributes to the study / discussion of obscure or large parts of the functional;
- Make the split large user story;
- Develop your ability to recognize that which was not obvious at the beginning;
I am not going to convince you that all stories can be broken up into small parts for up to 2 days, however, I state that most of your stories would fit this two-day method.
Regardless of whether you decide to just test my method or try to deal with the real problem on your project, I promise that you will see its benefits in a couple of days ... well, or I guarantee you a 100% refund of your money!
From translator
I would like to add the author and say that this method is well suited for high-level evaluation of user history and refer to the methods used in the preparation of estimeytov in extreme programming such as the Functional Points Method, recalculation of estimeytov based on the result - Yesterday Weather and Velocity Method, which are well described in User Stories Applied: For Agile Software Development
.
Take for example the situation when we talk about the difference between the implementation time of 1 hour and 2 hour tasks. It is quite easy for us to operate with similar figures and explain why the execution of one task will take an hour more time to complete. But when it comes to the difference between the 34-hour and 35-hour tasks, the rationale for such a one-hour difference looks completely incredible. Actually such a comparison shows that the best estimeyty depend on the size of the estimated tasks .
So we came to the conclusion that our story (User Story) should be divided into small parts (the smaller the part, the greater the accuracy of the estimates). How small should these pieces be? The answer to this question lies in the name of the two-day method.
')
Probably the best thing about this method is that there is only one rule in it - break your user story into parts not exceeding 2 days in implementation time.
This simple method will also lead to the emergence of many, not quite obvious, but good and useful habits:
- Contributes to the study / discussion of obscure or large parts of the functional;
- Make the split large user story;
- Develop your ability to recognize that which was not obvious at the beginning;
I am not going to convince you that all stories can be broken up into small parts for up to 2 days, however, I state that most of your stories would fit this two-day method.
Regardless of whether you decide to just test my method or try to deal with the real problem on your project, I promise that you will see its benefits in a couple of days ... well, or I guarantee you a 100% refund of your money!
From translator
I would like to add the author and say that this method is well suited for high-level evaluation of user history and refer to the methods used in the preparation of estimeytov in extreme programming such as the Functional Points Method, recalculation of estimeytov based on the result - Yesterday Weather and Velocity Method, which are well described in User Stories Applied: For Agile Software Development
.
Source: https://habr.com/ru/post/54090/
All Articles