Story Points Demystified — Part 2
I really like what Mike Cohn explained in one of his posts about story points, story points are about effort, despite so, when calculating the story points there are some factors we have to consider; these factors affect our estimation directly:
- Complexity: how complex the user story is.
- Risk: what are the anticipated risks related to this user story or feature?
- Uncertainty (doubt): how uncertain the requirements of this user story are?
These considerations can be incorporated when estimating the story points, but only to the extent they affect the expected effort to make the user story done. We don’t estimate the complexity points of the story, it’s all about effort. The story point estimation helps answering the common question in any project “When will we be done?” or “How much functionality we can have by a specific target date?”
The clients do not care about how hard your development team has to think to deliver the project, but they do care about when the team will be done with this project.
Story Points & Hours
Story points are all about effort, but this does not mean equating story points to hours. We can’t say something like “one story point = 5 hours” for instance. Story points allow team members who perform at different speed to communicate and estimate in a collaborative manner. Two developers with different qualifications (performance speed) can agree easily that a given user story weighs twice another story. They can agree easily that one user story deserves three story points if they agree that it will take three times compared to another story with one story point estimate, despite every team member might have different time estimation in hours for the tasks related to this user story. We were able to do so regardless the different speed of each team member, because it’s a relative sizing.
If you equate the story points to hours, the relative sizing won’t be possible and reaching consensus will be illogical. Usually team members will start estimating mentally the number of hours then map them to story points.
Planning Poker
Planning poker is a consensus based agile estimation and planning technique. It’s usually done (played) at the beginning of each sprint; preferably just before the sprint planning meeting, or after the user story writing workshops.
It’s important to have the right people to participate to run the estimation session efficiently and effectively; those people include the following roles:
- The delivery team:
All team members should be present when playing planning poker. Sometimes we estimate without the individuals in some roles, this is a bad practice. The estimate assigned to any user story in the backlog needs to represent the total effort to deliver that story, not only development effort or testing effort. All team members from different roles have to contribute because they actually have part of work to do to make the feature or the story done. It’s a collaborative activity done by the whole team.
- Scrum Master or Project Leader:
The scrum master is the team’s facilitator, he should be there to facilitate the planning poker session. If the scrum master has a technical experience in one of the technical areas related to the project, he has to contribute in the estimation rounds with the team. Usually the scrum master contributes in the estimation like any other team member.
- The product owner:
The product owner needs to be present in any planning poker estimation sessions, he does not estimate with the team, but he is present to:
- Describe each user story to the team before they estimate it.
- Answer any questions related to the user stories the team estimate.
How Planning Poker Works
To start a planning poker session, Each team member has a bunch of planning poker cards in his hand with values 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 (Fibonacci Sequence that we discussed in the previous post). These values represent the number of the story points in which the team will estimate each user story.
Then, the process will go through the following steps:
- The product owner reads the user story or describes a feature to the team.
- The team discusses the feature or the user story and asking questions to the product owner as needed.
- When the user story has been fully discussed, each estimator privately picks up one of the cards that represent his estimate.
- All cards with the estimators will be revealed or turned over at the same time.
- If all estimators selected the same value, that becomes the estimate of the user story.
- If not, the estimators discuss their estimates. Especially the estimators who have the high and low estimates start discussing and sharing their reasons for that estimate.
- After the team discussion, the team starts another round of estimation. Each estimator reselects an estimate card privately and all cards again revealed at the same time.
This process is repeated until the team reaches consensus about the estimate for each user story, or until the team decides to defer the estimation of a particular user story until more information can be acquired.