You’re probably aware that story points are meant to reflect the total effort to implement a user story or any product backlog item. I’m often asked whether a team can determine the total number of story points for an item by summing the number of points needed to program it, the number of points to test it, and so on by skill.
I want to offer five reasons why I advise against that.
First, it is a good thing when team members develop an appreciation for and understanding of the work done by those with other skills. That is, we don’t need testers to become programmers or programmers to become analysts. But each skill should have an appreciation for and understanding of the work done by the others.
If the testers estimating “testing points” that will later be added to “programmer points,” it is much harder to encourage this multifunctional learning.
Second, when work is split too granularly, the aggregated estimates can introduce more error than simply estimating the full work. Suppose a team estimates by skillset and includes five skills (programming, testing, design, etc.). Each subteam estimates their work to be ½ point. But wanting to avoid fractions and wanting to be safe, each subteam rounds up to one full point. In aggregate that means 2-½ points of work is estimated as 5 points. That is likely overcautious.
Third, estimating jointly ensures that everyone is estimating with the same set of assumptions. When estimating separately, a subteam of testers will make different assumptions than the subteams of programmers or database engineers.
Fourth, for some teams it can actually be more work. Estimating by skillset can take more total person hours than estimating a single value for a product backlog item.
Fifth and last, it is harder to ensure a consistent meaning for a story point. For points to be a useful planning tool, there must be a shared understanding of them across all functional subteams. The more skillset-based subteams, the harder it becomes to ensure that consistency.
I hope these five reasons can help you convince your team to estimate together. But should every team do it that way? Aren’t there some teams who might benefit from summing the estimates of skillset-based subteams?
I’m going to save that answer for next week.