How do you refine your assessment process?

Question

Estimating how long any given task will take will be one of the most difficult parts in software development. In my current store, we evaluate tasks in hours at the beginning of the iteration, but once the task is completed, we do not use it to help us in future evaluations.

How do you use the information you collect from past ratings to clarify future ones?

Answer 1

Today, one of the most interesting approaches I've ever seen for planning is Evidence Based, which is part of FogCreek FogBugz 6.0. See the Joel Blog Article above for a quick overview and some examples.

Answer 2

If the assessment fails, try to determine if it was just random (the environment broke, some some difficult error, etc.) or if something was not identified.

If the expectation were too big, determine what exactly you thought it took so long to understand why this did not happen.

Doing this is enough, we hope, will help developers in their assessments.

For example, if the developer believes that writing tests for the controller will take age, and then it takes less time than he imagined, the next assessment you make for a controller in a similar area, you can take this into account.

Answer 3

I value iteratively with my teammates until we reach a consensus. Of course, we make mistakes, but we do not calculate the “speed coefficient” explicitly, but rather use the experience gained in our new evaluation debate.

Answer 4

I found that time evaluation will show you. Interaction with other tasks, unforeseen circumstances or the impact of the project will inevitably change your time frame, and if you were constantly reviewing, you would spend a lot of time managing when you could develop.

So, for us here we give an initial assessment based on the experience of solving on time (we do not use a model, I did not find one that works well enough in our environment), but do not judge our KPI against this, and we do not assure the business that this deadline WILL hit. Our development approach here is largely reactive, and it seems to meet the needs of the business very well.

Answer 5

when grades are turned off, there is almost always a blatant reason that leads to lesson learning. Last from memory:

• The user interface assumed that .NET functions did not exist (the ability to insert a new row and edit its built-in GridView); The lesson is to test the functionality of the selected classes before evaluating. This mistake is worth a week.

• The ftp process assumes that FtpWebRequest can talk to a secure ftp server; it turned out that there is a known error with this class if the ftp server returns anything other than a backslash for the current directory; the lesson learned is google for the “error” and “problem” with the class name, not just the “tutorial” and “example” to make sure that there are no “gotchas” hiding. This mistake cost three days.

these lessons fall into the Project and Development Checklist, so they will not be forgotten for the next project.