Story Point Estimation and Planning Poker

Estimations are difficult. If a person can estimate the future with 51% accuracy (that is just 1% more accurate than tossing a coin) can make millions of dollars in wallstreet. That 1% makes lot of difference. There are various views on estimation and no estimation. I am not going into that debate. If you chose to do the estimation and so would like to forecast your team’s work, read on.

What is estimation? Estimation is a forecast just like weather prediction. Estimation can go either way because of known unknowns and unknown unknowns.

What is story point? This is a relative size and simply a number (1,2,3,5,8,13…) or a letter (S,M,L,XL ..). Relative to the complexity of the work.

Some talking points to ponder to understand complexity.

1. User story: What the story is saying? Is the understanding common across the scrum team members?
2. Design: Is it required to come up a new design or small modifications are sufficient?
3. Coding: Should we create many classes? Does user interface need extensive changes? Should i call one database or multiple databases? Is data transformation complex? How clean is the data?
4. Unit Testing: How many test cases should be written? Is the current testing framework sufficient?
5. System Integration Testing: Are the interfacing teams ready with data? Will we get timely help from them? What should we do if external teams delay?
6. User Acceptance Testing: Are users readily available to test? Is acceptance criteria clearly written for story? If users are not available should the team do UAT?
7. Deployment: Is there is a CI/CD (Continuous Integration and Continuous Delivery and Deployment) pipeline available? If it is manual, how much time should we spend?
8. Skills and Knowledge: Was this type of work done earlier? Do we have right skilled people in the team? Should we take one off help from external experts? Will they have time to help?

Above list is suggestive. You can build your own models depending on the type of work you do. Depending on the answers if the team feels the work requires more time, communication channels, coordination and resources (eg. infrastructure) the number or size may goes up.

Well…what is this size now?

Size is a number and it represents amount of the work just like kilo grams or kilo meters. This is not number of hours.

But then is there a direct relationship between size and hours?

There is… but it is not one to one mapping. If there are two people to run 10 Kilo meters, their timings will be different. Same with story points as well. Two people doing 5 story points of work will complete in two different timings. This being knowledge work adds bit more complexity to the equation. This is the reason, team velocity of one sprint is not sufficient to conclude as velocity. This needs to be over few months.

What is Planning Poker?

Planning poker is estimation technique which brings democracy to the work. Is democracy good for the world? Well, people may have different views. But democracy brings freedom, so new ideas and open thoughts. So let the team be the decision maker.

Who participates in the planning poker?

Entire scrum team. You may bring along designers and architects if they are not part of scrum team. This is an exercise not to write numbers on the wall, but to understand and agree on forecast without spending too much time.

How does this work?

I am using https://scrumpoker.online/ to do this exercise. Prakash is Product Owner, Shwetha is Scrum Master. Developers are Subhash, SumaLatha, Mohit and Arya. All the developers are ready to press buttons 1, 2, 3, 5, 8, 13, 20, 40, 100 for user story no.4321. Below are the possible story points.

Prakash reads the user story and description. Prakash answers any queries related to the story. What we can’t understand we can't estimate. This is the best time to get clarifications. After this each developer privately presses one number.

You can see some variation in numbers. Now the team discusses and come to one number. Remember, new number will not be an average of all the above. That is not democracy but compromise. After discussion, in this case everyone agrees that it is 13. In case of disagreement it is better to go for highest number. This is done!!!

Some tips:

• It is OK to have differences: Not everyone thinks same and estimates same. It is OK to have differences. Accept the difference as diversity but not as being dumb.
• Time box: Once Picasso said, A painting can never be finished it can only be abandoned. Same with estimates. Each user story should be time boxed. Sometimes intuition is the best tool.
• Do not force your ideas: It is good to have opinions and views. Do not force your’s on to other developers. Have a dialogue. Understand the real reason for the number. It is absolutely ok to lose your number and accept other’s number. This shows you are open to new ideas. Keeping the egos at check is the success mantra for planning poker estimation. At the end, team should do a great job and win the game of sprint.

image: http://blog.noweverybodysgotone.com/2013/08/scrum-quick-tip-estimating-ranking.html