Should You Quit Estimating
The No Estimates movement has its detractors even though many software teams have safely and productively quit estimating stories. It may not work for everybody, but it may work for you.
Kanban for example doesn't require estimates because there are no time boxes which makes pointing stories valuable. There's also no need for estimates when cycle and lead time provide the same information, but based on measurements.
What to Look For
Go back through your previous time boxes(sprints). The thing to look for is how many stories you've completed each sprint. If that number is about the same, all your stories are about the same size. The number you put on the story is no longer adding value.
If you want, you could even do some analysis:
Team A | Team B | |
---|---|---|
Sprint 1 | 4 | 4 |
Sprint 2 | 3 | 7 |
Sprint 3 | 5 | 2 |
Sprint 4 | 4 | 6 |
Sprint 5 | 4 | 8 |
Sprint 6 | 5 | 3 |
Sprint 7 | 3 | 5 |
Sprint 8 | 6 | 8 |
Sprint 9 | 3 | 4 |
Sprint 10 | 4 | 5 |
Average | 4.1 | 5.2 |
Std Dev | 0.994428926 | 2.043961296 |
Team A delivers about 4 stories plus or minus 1 each sprint while Team B delivers about 5 stories plus or minus 2.
Team A is not getting value from spending time estimating stories. The stories are already all about the same size and they consistently deliver about the same number each sprint.
Team B's stories are not about the same size. In order to see if Team B is adding value by estimating, they should do the same analysis but with total points delivered instead of stories. If they are consistently delivering about the same amount of points each sprint then their estimating is delivering value. They are good at deciding how big a story is and planning the same amount of points each sprint.
If Team B wants to get away from estimating, they can split big stories until all the stories would be estimated about the same. Then they would start delivering about the same number of stories and points. At that point they can consider skipping the estimating step and just deliver stories.