Why Does Planning Poker Use Story Points Instead of Time Values?Oftentimes, people get confused between story points and time values when estimating with Planning Poker. Well, we’re here to clear up the confusion.
Without a doubt, estimation is a difficult undertaking. It is one of the most challenging — if not the most difficult — facets of the job for software developers. It must consider various elements to assist product owners in making decisions that influence the entire team and the company.
Product development teams get frequently challenged by management to enhance the accuracy of their estimates, but this is easier said than done. These teams must not only work hard to figure out how to estimate, but they must also choose the best time to do it. Planning poker is a strategy that can help in agile estimation.
This article will shed light on Planning Poker, specifically, why it uses Story Points instead of time values.
Planning poker is a gamified strategy used by development teams to estimate the effort to complete project management activities. These estimates are more engaging and accurate than other approaches because they are based on the entire group’s input and consensus. Teams utilize planning poker cards, similar to poker cards, to help measure the number of story points for the required activities.
In a Planning Poker session, each project is assigned story points by the entire team.
Notably, estimated using a unit of measurement known as the Story Point is a systematic approach Scrum teams employ. Thus, a question arises: Why use Story Points instead of hours, days, or any other commonly used time values?
A Story Point is a relative unit of measure that individual Scrum teams decide on and use to generate comparable estimates of effort for accomplishing objectives.
The purpose of Story Points is to make team estimation easier. Teams analyze solely how much effort a product backlog item will demand compared to other product backlog items, rather than looking at it and predicting it in hours. With that, another question arises: What is the problem with utilizing time as a measurement unit?
In a nutshell, the answer is because one’s hour is not the same as another’s hour.
When a Scrum Master asks two developers to estimate the same work, they will develop two different estimates. While some of the variations may be due to gaps in the specification or misunderstanding, the truth remains that developers have varying levels of knowledge and experience. Therefore, the same work will take longer or shorter.
When those same two developers get asked to rate the amount of effort required to execute one product backlog item against another, the Scrum Master is considerably more likely to reach an agreement.
Ultimately, story points get provided to break down work into smaller portions better to address uncertainty. This option helps teams realize how much they can do in a given amount of time and create consensus and commitment to the solution over time. Although it may appear counterintuitive, this abstraction is beneficial since it forces the team to make more difficult decisions about the difficulty of the work.
Here are some more compelling reasons to employ story points:
- Non-project work that inevitably slips into workdays, such as emails, meetings, and interviews that a team member may be participating in, does not get considered by dates.
- Dates have a strong emotional component. Emotional attachment gets removed by relative estimation.
- Each team will estimate work on a slightly different scale, resulting in naturally varying velocity.
- Teams can swiftly assign points without much dispute once they have agreed on the relative effort of each story point value.
- Story points incentivize team members to solve tasks that are challenging rather than time-consuming. This option helps team members focus on delivering value rather than wasting time.
Story points, unfortunately, are frequently misused and misunderstood. When story points get used to criticize people, allocate detailed timetables and resources, or measure productivity, they go wrong. Instead, teams should use story points to determine the scope of the project and its priority.
There is no need to work weekends to make up for underestimating a project's scope. Fortunately, there are a few things teams can do to make agile estimates as accurate as possible:
The product owner is responsible for prioritizing the backlog, an ordered list of work that provides brief descriptions of all required features and fixes for a product in agile development.
When the engineering team starts estimating, questions about requirements and user stories are common. And that is a good thing: those inquiries help everyone on the team understand the project better.
Breaking down work things into granular chunks and estimations via story points aids product owners in prioritizing all areas of work. Thus, it is not uncommon for a product owner to reorder items on the backlog after receiving estimates from the development team.
It is critical to include everyone on the team — developers, designers, testers, deployers, and anyone else essential to the project. Each team member adds a unique perspective to the product and the labor involved in delivering a user story.
If, for example, product management wishes to accomplish something seemingly straightforward, such as support for a new web browser, development and QA must weigh in because their experience has shown them what dragons lay beneath the surface.
Retrospectives allow the team to incorporate lessons learned from previous iterations, such as the accuracy of their estimates. Many agile solutions, such as Jira Software, track story points, making it easier to reflect on and re-calibrate estimates. For instance, look up the team's past five user stories with a story point value of 8. Examine whether each of the tasks required the same amount of effort. If not, explain why. Use your newfound knowledge in future estimation discussions.
Project management for agile teams can entail a variety of difficult decisions, ranging from managing product owner expectations to defining quality standards that are not yet defined. Estimation, however, like everything else in agile, is a discipline. With practice, teams will only get better and better.
As you prepare to use Planning Poker in your next product roadmap planning meeting, consider Async Poker.