If you do Scrum at work, you might be very familiar to the estimation in Planning 1. My PO has once complained to my team that why it took too long for estimating just a story. Wasting time results in the planning timebox is violated.
I give you some advice from my experience:
Estimation is estimation, not measure.
When you read some requirements, you see some risks but you actually don't know how complicated it will be. Don't try to influence the others by explaining how to do it in too detail. Just keep in mind that you know the business domain pertaining to customer needs and estimate how much effort you will spend for it. The effort should be compared to your baseline one that you use for a simple requirement.The bottom line is we do "relative estimation", not absolute estimation. For example, you are asked to estimate the height of a building. Basically, you just need to answer "how many times higher is the build than your height"; you don't have to give a accurate number.
Don't waste time for convincing the estimation points these are nearly the same.
Playing planning poker in Planning 1 somehow is interesting, but you should be careful. In many cases, you need to explain why your number is different from the other members (the largest number or the smallest one). If the different is very much (for example, between 3 and 8), the worth explanation is necessary. However, most of members have the same number excepting few members, the team don't need to force them to prove why they choose this number. For instance, there are 7 members in your team. Only two members choose 5 points and the rest of members choose 8 points; then your team just goes with 8 points. The exception case is only when the person has a strong concern and she wants to clarify it.The main point is that you don't need to influence other members by proving how difficult to implement the requirements; these points should be discussed in Planning 2. What a waste of time if the team discusses too much about how to do the use story in Planning 1.
References:
[1]. http://www.slideshare.net/ScrumBreakfastVietnam/hcm-scrum-breakfast-agile-estimation-story-points
[2]. https://www.meetup.com/Scrum-Breakfast-Vietnam-Agile-and-Scrum-Meetup/events/233057237/
Comments
Post a Comment