Agile time estimation is one of the most efficient ways to determine when your product will be completed and when you reach certain milestones. When envisioning efficient estimation, the first thing that may come to mind is time. Likewise, Agile does accommodate this estimation form, through the specific measure of hours or days. Hours or days show how long it will take to complete a certain task.
However, you may not know that there is a different way to estimate through Agile programs: through effort. Effort appears with the measure of story points. Story points can be based on size, complexity, or risk involved, and in effect, shows how much effort or work the task will take.
Time and story points are both unique ways of estimating tasks and stories. That said, they cannot be used interchangeably. In fact, one or the other may be more beneficial for your project and your development team. Follow along with this article to learn what each one is, and the advantages of and the disadvantages of each. From here, you can determine which one is ideal for your product development and management.
The go-to estimation method is through time. Afterall, most things do run on time such as work hours, milestone dates, and investment portfolios. As such, most Product Managers, Product Owners, and Key Stakeholders wish to know how much work a team member can complete in a specific amount of time. In this way, management can not only predict when a specific task should be completed, they can estimate when the whole project will be finished. They can also hold team members accountable for their work through this method, easily recognizing when targets have not been met on time.
Time estimation may be the simplest type of estimation, especially since Agile estimation is a collaborative method involving the whole team. With such a common standard across the corporate world, most team members will readily understand what the measure means and how to use it. For this reason, teams can more easily determine the amount of hours it would take them to finish a task.
However, time estimates can also be a major disadvantage for certain teams and projects. First off, some tasks can simply not be determined efficiently with time. Particularly, this may be true of incredibly complex tasks which have not been completely defined yet. Likewise, this may be the case with large tasks where time can easily be underestimated or overestimated.
Second, within Agile estimation discussions, especially if they are repeating, one person often can convince a whole group of their position. While this is true with any measure, it is especially easy to do with time. In discussions, time can be construed as merely theoretical; this can lead people to believe they complete something faster than in reality with enough persuasion.
Finally, time is a well-known stressor. If estimates are off even slightly, it can place team members and management under unnecessary stress. Often, this kind of stress can lead to serious mistakes or missed opportunities to create something incredible. Overall, time can impair performance if it is not carefully determined.
Unlike time estimation, story points estimation tackle the difficulty of a User Story. Of course, they can also be used to estimate tasks from the Product Backlog as well. Story points relate to any or all of the following: the amount of work to be done, the complexity of the work at hand, and the risk involved in carrying out the work (also known as the uncertainty).
Story points assign a numerical value towards this evaluated effort. However, it is important to understand that these numbers have absolutely no meaning outside of their specific compared context. They only mean something when compared with another story or task that has also been evaluated with story points. For instance, one story may pull an effort of 5 which only means something in comparison to another story which has an effort of 8. Against 8 story points, 5 story points is relatively easy while 8 story points proves more challenging.
Recently, story points estimation is becoming more popular than time estimation. This is especially true amongst software project development and management, because:
- It is accommodating for large or complex tasks: As aforementioned, these types of stories are hard to estimate through time due to uncertainty. Story points actually integrate risks (or uncertainty) into the estimation.
- It allows for different strengths: Different development team members have varying expertise and experience. Since this is the case, they will work at different speeds; Developer A may take considerably longer to write a program than Developer B which means a consensus reached on a time estimate does not help either developer. With story points, however, a consensus can be reached which encompasses the needs of both developers.
- It decreases stress: Focusing on effort or difficulty is more flexible than duration. Timelines may be helpful, but they are not the determining factor in whether team members are competent or the project is successful.
- It is more collaborative: As mentioned earlier, it is easy to convince team members to jump on board with a particular time estimate. With story points, it is easier for team members to think about tasks at both an individual and team level in each discussion.
- It gives team members more accountability: It is a common theme in project development to find a few key team members to take on the burden of finishing a project in time. Under story point estimation, there isn’t a hard deadline giving accountability back to every team member.
On the flip side, story points are slightly harder to explain and comprehend than time estimates. It requires learning how to compare to other Stories or tasks, or completed Stories and tasks from previous projects. It can be hard for team members to always keep this in mind during estimation, until they get the hang of it.
Story points may be the best estimation strategy for most Agile teams today, however, time estimation may still be ideal for many development teams. No matter which estimation method you choose, make sure you are using state-of-the-art Agile programs such as Agile Scrum Planning Poker for Jira.