This article is well-timed for our discussions around Agile and best practices. I hope you find it useful in how to handle equating points to hours.
VIDEO: Coaching Tips to Stop Teams Equating Points to Hours
Today’s post introduces the first installment in a free series of training videos to help teams use story points to create estimates. The training will be available until Wednesday, October 28, at 9 pm Pacific.
To watch the first video and find out when the next video is available, sign up here.
Over the next week, some new (and free) training videos will be released to tackle common problems teams face when estimating with story points.
Earlier this year, a survey to discover what challenges people had was sent out and got more than 2,400 responses from Scrum Masters, agile coaches, product owners, and managers, who highlighted the following issues:
- Team members equating points to a time
- People refusing to estimate or demanding to know every detail about a story before estimating
- Tension with stakeholders who treat estimates as guarantees
- People with different skills and experience unable to reach an agreement
- A lot of wasted time and frustration
If you’re struggling with the same issues, I think you’ll enjoy these videos. It’s free to register, and you’ll have the chance to comment and discuss the lessons shared in each video.
Get instant access to Video #1
At the end of the training, there will also be an option to unlock more in-depth training (details about that coming soon).
Video #1: Equating Points to Hours
It’s no surprise that after years of using time-based methods to estimate work, teams can struggle with the abstract nature of story points. Some people find it difficult to detach from the idea that a story point should equal some hours.
But unless you change your perspective, not only will your estimates have no value, you’ll experience endless arguments between team members who cannot agree on how long something will take. When you equate points to hours, a common situation is a junior developer saying to a senior developer:
“Sure, it’s 5 points if you do it, but if I do it, it’s 8 points.”
And they’re right…if they only think in time.
Some teams think that this won’t be a problem if they know in advance who will do the work, but in my experience, that’s not the case. At some point, multiple team members will work on one story. Sure, one person may take the lead on programming a feature, but it will still need testing, designing, and so on.
As a result, everyone needs to estimate together…and agree. And you can’t do that if people equate points to hours.
Watch Video One now to discover:
- Why it doesn’t suffice to tell team members not to equate points to a time
- Why you shouldn’t give in to a team’s desire to equate points to hours, even if it seems the path of least resistance
- The tell-tale signs your team is thinking in time
- A simple overview of why points are abstract, relative, and effort. This is a great starting point for introducing story points if your team is new to the concept.
- Two practical coaching techniques you can use to encourage relative estimation
This video will help you start to conquer those deep-rooted problems and bad habits teams have picked up from equating points to a time.
Your new techniques mean you can save time—estimating rather than arguing—and have more peaceful and productive discussions about the effort required to deliver your work.
Does your team struggle with equating points to time?
Please weigh in on this one in the comments since we’re going to be talking all things to do with story points and estimating over the next week. What signs do you see of teams struggling with this problem? Let me know in the comments.
