One of the popular mechanisms to estimate story points as a team is planning poker exercise.
It’s an awesome technique but it may become a challenge for some teams. For instance, a team estimates story points separately as developers and testers. Later, they add up those points to arrive at resultant estimates.
Some teams get into endless discussions to ascertain if the estimate should have been 2 or 3, 5 or 8 or maybe 7.
It looks like, the primary goal of planning poker exercise is to arrive at the correct estimate.
But that’s not the point!
Before we understand why, let’s know a bit more about user-stories.
What are user stories?
A user-story doesn’t become user-story just because you write them in a particular format (“As a…I want…so that”). It’s also not about to write them on 4×6 index cards or placing them in tools like Jira.
User stories are all about “Requirement by Collaboration”. Hand-overs between business stakeholders and development team or even within the team are replaced by frequent involvement and discussions.
In enterprises, domain and technical knowledge are often spread among different people. A discussion among all these people often leads to good questions, options, and product ideas.
If requirements are just written down and handed over, this discussion does not happen. Similarly, if developers and testers estimate them separately, this discussion doesn’t happen.
Planning Poker and Conversation
Planning poker helps team-members in having a conversation on the requirement without getting influenced by peers. That’s the reason, each estimator privately selects a Planning Poker card representing his or her agile estimation.
In case, estimates vary, people explain their reasons. With this conversation, people understand the requirement a bit more and come on the same page.
Developers, testers, business analysts or UX designers have varied perspectives. If they estimate in isolation, they’ll never get to know the perspective of others. That way, they might lose the opportunity to understand the requirement in totality.
So as you play planning poker, the goal is not to come up with perfect estimation.
The idea is to understand the requirement in totality.
Story point as a number is just a side-effect of planning poker exercise.
More on Story Points and Agile Estimation
This post is a part of a blog post series on story points and agile estimation. To read rest of the posts on the subject, please navigate to All About Story Points and Agile Estimation Series.
Nice. Highlights the essence of this planning poker exercise to deep dive into requirements through discussions and understand them better before starting work.
I disagree with the statement – “Story point as a number is just a side-effect of planning poker exercise.”
Story points are a measure size, complexity & uncertainty in the user story (or requirement). Story points are preferred because they are a non-time referent way of estimation. Also, story points never decay with time and do not take into consideration a individuals years of experience (in other words, its a consensus based approach to arriving at a number which has nothing to do with time).
Also, IMO, “The idea is to understand the requirement in totality.” is a statement with (*) in the end; Planning poker doesn’t ensure that the requirement is understood totally – its the 3Cs of a user story that makes it a tool for collaboration tool.
However, the technique of planning poker does help get into the details of the requirement – enough detail that the team is confident estimating; and the team will be confident estimating only when they feel they have a good understanding of the story (including the dependencies, if any).
I agree with your perspective. However, what I understood from original post is that intent of planning poker should be to get all have a common understanding about a requirement irrespective of their roles. Once this is achieved, consensus will be achieved and one can arrive at an agree story point estimate. Focus should be requirement clarity rather than arguing over number of story point to be assigned to a backlog item.