story estimation

There is not such thing like right or bad way of estimation, especially while you have mentioned a story, which implies that you think about planning poker approach. What is valuable is the discussion that is triggered and occur around the act of estimation, not the number that in the end you had agreed upon to write down on a story card - it is barely a shadow of understanding that (should) happened.

Are you sure that as a team you are pursuing the right thing? A set of guidelines, what to consider and what not in estimation, that everyone will must follow?

Three key points may be helpful to remember:

• Estimates should be done by the people who are doing the work.
• Estimates should include all of the effort and complexities in getting the work done.
• The Definition of Done can help guide the team in creating estimates and selecting Product Backlog Items for the Sprint.

If your Definition of Done includes not only the development effort but also unit testing, dev testing, and peer review, then the estimate includes all of those. If your Definition of Done includes anything else, that should also be included in the estimate. You can refine the Definition of Done as the team matures, learns more about what is expected or needed, and develops a better way of working.

My team includes,unit testing + dev testing + peer code review in all of the estimations they put on a story. Is that a right way to do it?

Would that cover the work needed to complete the story to "Done" standard?