Scrum Time Estimation

In the new company, product managers who do not understand software engineering often force developers to make very unreliable time estimates. Common scenarios include the following:

A time estimate is required when the demand is not refined; For example, in a sentence to describe what kind of function to do, but what the specific page length, interaction is not fixed down the time, asked to give time to estimate;

To negate the time estimate of the researcher according to the product release time; For example, I have personally seen, there is a function, five days to go online, research and Development estimates for 7 days; Product said, no, revaluation, five days after the release; Research and Development said that this function seven days do not finish Ah, overtime also do not finish AH. Product says, no, then you find a way. So research and development compromise, OK, estimate 5 days. Product is very happy, said, said 5 days before the line. So the development of hard to work overtime. To me, in this case, the time to estimate a p is purely a waste of time.

Constrained by the existing code framework resulting in a far more than expected product expectations; I believe that a lot of developers will listen to the product complaints, do not add a XXXX, how to two days, even if the development of careful explanation is due to existing code framework problems or unreasonable design caused, most products still feel not acceptable, Even if they don't understand it at all.

It is considered that the time estimation is not acceptable, it is the level problem of the research and development personnel, the better the technical level, the more familiar with the existing code and business process, the more experienced researchers can give more reliable estimation. However, there are many uncertainties in the software development process, changes in demand, insufficient refinement of requirements, technical implementation and the original technical framework, and so on, will affect the actual implementation of the final time; not to mention that developers are not guaranteed to spend all their time on meeting their needs every day. Therefore, I personally do not agree with the time to estimate whether or not to conduct performance appraisal behavior.

Bugs do not accurately estimate time; it is easy to fix the bug time by spending it on location analysis rather than solving it. The correct estimate of the bug must have found a reason, so this is doomed to some bug is not accurate estimation of time.

All right, spit it out, and look back at the time when we used scrum to estimate it. There is no modification to the bug, only new requirements are involved. At that time, all of our needs were split into task levels.

First, the task that can be estimated in the scrum sprint, the corresponding requirements must be clear, after the review, the developers and testers reached a consensus. To be clear, try not to influence the implementation of scrum because of changes in requirements and ambiguity;

Secondly, the task that can enter the estimation process must be carefully split from a technical point of view or functional angle, with a clear description. The finer the granularity of a task, the more accurate the estimate. To estimate the time spent on a product, the error must be large, but it is relatively accurate to estimate the time to write a method or a class. The split of the task is often done by architects and technical managers because of their understanding of the product, their technical understanding, and their familiarity with the existing code, as well as the ability to reuse it.

After the first two steps, it should come to the point where everyone in the team is able to see the description of the task, it is clear what the task is doing, what the technical difficulties are, what interactions are needed, whether there is ready code to reuse or reference. Frankly speaking, the implementation of this task generally does not affect the structure of the change, because when the task is split, it must be the first to set the structure to do.

At the time of the specific estimate, we used the universal poker method at that time. That is, each person will have a number of signs written in hand. It was as if the numbers were 1,2,3,4,5,8,13,16,20, and then each person made the cards according to his own understanding, and finally took a relative average value. But at this time, if some people are very different, especially those who are most likely to take the task, the difference between estimates and others is very large, then generally speaking, there is a difference in understanding, this time depends on whether people really understand this task.

Another point is that if the final estimate is particularly large, say, for more than two days, there is no doubt that the task is ambiguous or can continue to be split, or continue to split or focus on these corresponding tasks during the implementation of scrum.

The above is basically a process of estimating the approximate time. This estimate, in most cases, is relatively reliable, because the team members of the individual ability and the actual difference, but often the difference is not big. And in the process of estimating and discussing, the team members can also achieve the purpose of knowledge sharing and information exchange, which is very advantageous to the team's growth.

Of course, many times are not so idealistic, not every task can do that kind of split. So in this case, sometimes we are directly not included in the sprint, but will let some senior engineers or architects to do some pre-research work, paving, stepping on the pit, this time, although the task seems to spend time is still uncertain, but at least everyone understands the risk of the project where, The low-risk part should ensure smooth interaction and accomplish the goal of iteration.

In fact, this method will have some shortcomings in the concrete implementation process. As far as my own feelings are concerned, the main drawbacks may be the following two points:

1 The architect who is responsible for the task splitting or the senior engineer who is in charge of the pre-research is sometimes too heavy, and according to the above description, it is often necessary to split and pre-graduate some of the unclear tasks in the backlog before the next sprint, which is actually a time-consuming, plainly speaking, Some of the architecture and design work is done at this time. Architects and senior engineers often take on the implementation of many of the tasks in scrum, which can be a bottleneck for the entire scrum if the time allocation is poor and the split work is not done well. One way to alleviate this is to put the architecture, the split, the design, the pre-research also set up tasks separately, into the sprint, to tolerate the inaccuracy of these estimates;

2 The seminar is time-consuming when the task estimates diverge; In many cases, these discussions are meaningful, but they do not mean that it is meaningful for everyone involved in estimating. In particular, team composition is less than the "self-organizing" and "mutually replaceable" requirements of scrum. Some of the improvements that can be made are to allow task-independent personnel to abandon estimates and abstain from voting, and to try not to use time estimates to link performance. Some team leader will think that failure to complete in the estimated time is a poor performance, the time to estimate more than others is bad performance, and so on, this will affect the objective estimation. Believe that team members will try to give an objective estimate and encourage team members to make an objective estimate. If you can't trust the team members enough, or if leader think the team members are not worth the trust, then don't go to scrum, and don't force team members to give estimates, you don't trust your team, it's better to just fill in the numbers as your boss says.

In addition, it is also possible to adjust the estimation of certain tasks during the implementation of scrum, which is also easily reflected by the burn down graph. Because many of the details are found in the implementation process, adjustment estimates can reflect more accurately the actual situation and risks of the current project.

At review meeting in Sprint, the review of the estimate should also be an important link. This helps to make more accurate estimates in the subsequent sprint process and helps the project to be more controllable. For example, when our first sprint was done, we found that everyone missed the code review time when estimating:)

Scrum Time Estimation