In scrum, we have a preference for using story points instead of hours. We've discussed the reasons why in the post below.
Usually, when we are estimating in hours, the focus on answering the question "How long it may take us?". It's the technique of coming up with the best possible estimate based on experience. We're trying to come up with an absolute number for the task at hand, which is very hard. Also, depending on the varied capabilities of people, one person could spend 10 hours doing a task whereas another person could spend 5 hours doing the same task. In such a scenario, it might be hard to decide the amount of time it takes to finish the task. The essence of estimating in points is that it is based on relative sizing. When estimating in points, you focus on relative sizes or complexity of estimated tasks/stories/whatever. So, you usually take some of your tasks and apply one of the point values to them, and later, for each other task, you try to answer the question "How big is this task in relation to those I've already estimated". For example, it is easier to agree that creating a user registration form is a much smaller task as compared to developing the shopping cart functionality; at least most people would agree to this. This approach reduces variability in estimates and allows individuals with differing skill sets and speeds of working to agree. After completing a couple of projects, you would have a history of how many points the team covers in a given time interval, i.e. sprint or release. That becomes the team's velocity and provides the basis for planning future releases.
To learn more about such topics in scrum, please feel free to attend to our 2 hour free scrum webinar. Click here for registration.
Test your scrum knowledge with the Foundational certification in Agile Scrum (FCAS™) exam. To register and take the exam, click here.
Comments