What's the Point of Points

Sizing is an essential part of User Stories and should be considered in two different aspects: the size of the story and the size of the story. I know, sounds redundant, but here is what I mean: 

• The Amount of Work - How much work is encapsulated in a single story? We want to focus on having small, bite-sized pieces of functionality. 
• The Number of Points - How large is the story from the perspective of number of relative points 

Every team, regardless of whether your team uses Scrum or Kanban, should be sizing stories to ensure that they have an appropriate amount of work. Scrum teams in particular may also point their stories. Once a team matures, and stories become more consistent in size, then the team may decide that points are no longer needed. These mature teams measure progress and velocity by number of stories rather than the number of points. 

For teams that are using points, particular care needs to be taken to ensure that points continue to be valuable. First, we need to understand the purpose of points: 

• Visually show the amount of work or complexity of a story 
• Indicate when stories need to be broken down further 
• Help the team to plan accurately by showing team velocity 

Unfortunately, points can easily be used to propagate anti-patterns that undermine the effectiveness of the team. I’ve seen this particular anti-pattern in several different teams, on several different clients as well as with previous employers. Here’s how the anti-patterns general arise: 

Teams set goals knowing that there are many risks and unknowns every sprint. Management takes a stated goal as a firm commitment. Management berates the team for not closing out enough points and fulfilling their commitment. The Teams resort to bad behaviors to avoid berating: 

• Working nights and weekends – which we have seen result in more defects and also many professional studies have found the same. Unfortunately this bad behavior is considered the norm for most teams 
• Inflating points – putting more points to each story to make it seem like more work is being accomplished (i.e. would normally be 2 points, but to avoid getting beat up we will make it 6 points). We are currently seeing this behavior on many of the teams ( I hear about it in their team retros) 
• Putting in bogus stories – similar to inflating points, but in this case it is inflating points for stories that don’t mean much. Again, we are seeing this on several teams already 

Because of the avoidance behaviors, the team is able to “accomplish” their goal. Management praises the team for accomplishing their goals. Bad behaviors are reinforced, so the team continues with the bad behaviors. Points are now just a tool for reporting to management and are not useful for teams as planning tools 

Before continuing I want to be clear that points can, and should be, valuable indications of team progress, highlight process issues and enable long term planning. Since points can be so valuable, what can we do to ensure they are used correctly? Here are a few things that I have found to be successful: 

• Don’t reward or punish for points - Yes, I know that you’re pleased that your team completed more points this sprint than ever before and that you want to buy them all doughnuts… but find something else to celebrate for 
• Treat points as a process indicator, not an objective - working software is the objective 
• Don’t ask the team to increase the number of points in a sprint - Ask how the team can be more consistent. In finding how to be more consistent, the team will uncover process obstacles which will lead to process improvements 

I’m sure that these aren’t the only things that work well, so what have you done to ensure that points have the appropriate meaning?