My suggestions to do estimation

1. Do not do any estimation before the following done:

(1) First of all, list all the tickets, and make all the team members to understand the requirements of all the tickets well. If not certain, we have to try to ask questions and clean any uncertainty.
(2) Code study for each ticket, so that we can estimation better, and we can discuss with other team when we find our code has some difficulty to meet the requrement in the first time.
   In code study phase, we can note any suggestions which is detailed in code level, such as changing line:xxx in xxx.java file. Then, when we do the ticket, we can share and then everyone can finish it more quickly with this information. But don't submit code in this phase.
   When code study, think out all the solutions and prepare to discuss in a meeting.
(3) After Code study, discuss and select the best solutions that all members pass and nobody disagree. The solutions should be the most suitable solutions in the team.
(4) know about the the working schedule of related teams, because their schedules may influence our schedule too much.
(5) know about the build schedule, because the build schedule may influence our schedule too much.

(6) We should estimate and have enough time to the above 5 tasks. I think it is also reasonable to estimate two weeks or more to do above 5 tasks. Making the detailed estimation documents can be the First Mile Stone -- the most important mile stone.

2. Estimation: (in this phase, we don't have any uncertainty)

(1) note down what to do, how to do, picture is better.
(2) consider it is not possible to 100% code writing, we have so many meetings, we should discuss, and go out for fresh air, and so on. And in more cases, we may have some emergency cases (which is out of plan) to do; or some strange technical issues to discuss and fix, or some problems found when doing half of the work, and so on.
    Maybe 50% is reasonable, and we should adjust the percentage next time according to history.
(3) we should estimate some time to make our code better when doing ticket, such as code review, testing, and refactory. Refactory should do with any ticket each day, don't expect to do a large refactory after release, because it is more difficult at that time, and many times it is less efficiency.
(4) consider we should have some time to do testing every tickets before build, and we should also have some time to build.

(5) share our estimation plan to each member, so that they can know all the progress. IceScrum and Burdown chart is better.

3. Task assignments

(1) try to apply "horizontal lines" mode instead of "vertical lines" mode.
   In vertical mode, everyone should be super man to learn everything, and change others' code easily. That may influence others' design, and produce some bugs.
   In horizontal mode, GUI guys focus on GUI interface, and don't need to know many server logic; server guys focus on service, and don't need to learn some GUI trips. What they discuss is the service interface and data structure to communicate between each other. They can work separately and don't need to wait the other one, just mock up some data and then integrate together. GUI guy don't have to review code of the server guy, and vise verse.
(2) switch the role periodically (Maybe half an year to 1 year is OK). So that each member can know all the knowledge and learn all the technologies. If another one is absent, he/she can take the all task easily. In this way, code review and knowledge share is very very important.

---------------------- 本博客所有内容均为原创，转载请注明作者和出处 -----------------------

 Author：刘文哲 (Wenzhe Liu)

 Email：[e-mail]

 Blog：http://blog.csdn.net/liuwenzhe2008

---------------------------------------------------------------------------------------------------------------------