Problems with preparing estimates for tasks? Use the two day method.
- Transfer
The biggest problem in the software development industry is the inability to predict task completion times with reasonably high accuracy. Very often - this is due to the fact that the developers allow themselves to give groundless assumptions on completion time for sufficiently voluminous or vague tasks.
Take, for example, the situation where we are talking about the difference between the time it takes to complete 1 hour and 2 hour tasks. It’s quite simple for us to operate with such numbers and explain why it will take no more time to complete one task for an hour. But when it comes to the difference between the 34-hour and 35-hour tasks, the rationale for such a one-hour difference seems completely unbelievable. Actually, such a comparison shows thatthe best estimates depend on the size of the tasks being evaluated .
So we came to the conclusion that our stories (User Story) should be broken down into small parts (the smaller the parts, the greater the accuracy of the estimates). How small should these parts 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 that do not exceed 2 days in terms of implementation time.
This simple method will also lead to the emergence of many, not quite obvious, but good and useful habits:
- It will contribute to the study / discussion of obscure or large parts of the functional;
- Forces to share large user stories;
- Develop your ability to recognize what was not obvious at the beginning;
I’m not going to convince you that all stories can be broken up into small parts lasting up to 2 days, however I argue that most of your stories would fit this two-day method.
Regardless of whether you decide to just check my method or try to cope with a 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 supplement the author and say that such a method is well suited for a high-level assessment of the user story and refer to the methods used in preparing estimates in extreme programming such as the Functional Points Method, recalculating estimates based on the result - Yesterday's Weather and Velocity Method, which are well described in book the User Stories an Applied: For the Agile Software Development
.
Take, for example, the situation where we are talking about the difference between the time it takes to complete 1 hour and 2 hour tasks. It’s quite simple for us to operate with such numbers and explain why it will take no more time to complete one task for an hour. But when it comes to the difference between the 34-hour and 35-hour tasks, the rationale for such a one-hour difference seems completely unbelievable. Actually, such a comparison shows thatthe best estimates depend on the size of the tasks being evaluated .
So we came to the conclusion that our stories (User Story) should be broken down into small parts (the smaller the parts, the greater the accuracy of the estimates). How small should these parts 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 that do not exceed 2 days in terms of implementation time.
This simple method will also lead to the emergence of many, not quite obvious, but good and useful habits:
- It will contribute to the study / discussion of obscure or large parts of the functional;
- Forces to share large user stories;
- Develop your ability to recognize what was not obvious at the beginning;
I’m not going to convince you that all stories can be broken up into small parts lasting up to 2 days, however I argue that most of your stories would fit this two-day method.
Regardless of whether you decide to just check my method or try to cope with a 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 supplement the author and say that such a method is well suited for a high-level assessment of the user story and refer to the methods used in preparing estimates in extreme programming such as the Functional Points Method, recalculating estimates based on the result - Yesterday's Weather and Velocity Method, which are well described in book the User Stories an Applied: For the Agile Software Development
.