One of the hardest concepts for some teams to understand, especially when they first start using user stories, is that of story points. “What is a point?” they ask. “Is one point equal to one day? Six hours?” I once saw a chart on a Scrum Master’s wall showing story points as multiples of six hours. #facepalm I advised the Scrum Master to take it down and burn it – or I would. I did get a great recommendation, though, which I didn’t do but thought long and hard about doing. It was this:

1 point is about equal to 1 point
2 points are about equal to 2 points
etc.

I laughed about it, but I know a lot of coaches struggle with this, especially if the Scrum Master is the only coach the team has and the only training they had was a 2 day CSM (Certified Scrum Master) class. We, as the community, are doing something of a disservice expecting that people can take that training and effectively transform a team (let alone an organization) with just that training.

User Story Points

Story points are, of course, the way we measure relative “effort” for a particular story against other stories. A common technique is to do , a “game” where every player estimates the size of a story in points using the modified Fibonacci scale and tries to come to a consensus (or at least agreement) on the points for the story. One of the great elements of Planning Poker is that it forces conversations. People who estimate outside the norm explain their reasoning. This usually results in the team having deeper conversations about the story. Sometimes it’s a misunderstanding that results in a very low or high estimate. Sometimes it’s an insight that someone has that others on the team didn’t have. Whatever the reason, it fosters conversation and creates a shared understanding of the work to be done. It’s a great tool, but what if your team has no experience using story points? Or is struggling to grasp the concept and keeps trying to convert to hours/days? What to do then?

A Brief Interlude

 

I once had a team doing a PI Planning (a SAFe Program Increment) session and they were getting wrapped around the axle trying to figure out how to estimate the work. They were so wrapped up in Planning Poker trying to come up with numbers that they were losing sight of the main goal – relatively sizing the work. A story point consists of more than just effort (which is why the conversion to hours/days fails). I look at them through the lens of CURSE: Complexity, Uncertainty, Risk, Scope, and Effort. (I wrote a post on LinkedIn describing the details – you can view that ).

 

For this particular team, I decided that a simpler approach was going to be more useful. So I pulled all of the stories from the wall and put them in a pile on the table. I then grabbed the first story and put it back on the wall. “This is your first story,” I told them. “I don’t care how big it is, but you’re going to size everything relative to this story.” I then took the next story off the pile and asked them “Is this story smaller, larger, or the same size as the story on the wall?”

An Epiphany, of Sorts

There was some grumbling about being a different kind of work, but I kept them focused on talking about it. What’s needed to complete it? What’s different about it versus the story already on the wall? Is there more complexity? Less certainty? Higher risk? More effort?

We could then place that on the wall in the appropriate place and did the same thing with the next story in the pile. And so on, until the pile was placed on the wall in different columns of relative sizes. And then I pointed them using modified Fibonacci. We did end up with a half-point story (which is a little unusual) but almost everything else flowed into points of one to twenty. We knew the twenty-point stories would need to be broken down further (awesome) and that almost everything else was something we could complete in a sprint.

The Alternative

When you’re working with a team that’s struggling like mine, relatively size things on the wall. Pick a story at random. You don’t need to take the smallest (although that is an option) or one that you can complete “in about a day” (which is what SAFe recommends). Just pick it at random and put it on the wall. Have the team talk about it. What needs to be done to complete it? Discuss the acceptance criteria. Make sure everyone has a solid understanding of the CURSE elements needed to fulfill the story. Congratulations! That’s the hard part.

Next, take the next story on the pile and put it up on the wall. Ask the team – “Is this smaller, the same size, or bigger than this story?” Guide the conversation so everyone comes to a consensus. Then put it on the wall in the appropriate place. Rinse and repeat for all the stories you want to refine in that session.

The Nitty Gritty

We still want to track team performance, so you want to assign story points to the stories. Start by assigning 1 story point to the far left column and then just go up from there (1, 2, 3, 5, 8, 13, 20, 40, 100, ?). Some tools (like ) have agile estimation boards built into the software so you can do this electronically. And Rally used to assign points automatically based on the columns (this was configurable in Rally – I’m not sure about CA Agile Central, but I’m sure it’s the same or similar).

Customizing for Your Teams

Estimation boards can (and should!) be customized per team. Make it entertaining for your team. One of my former coworkers had a team who used column headers like: “Why Bother?”, “Fun-Sized”, “Just Right”, and “Caguama”. Everything fit into one of those columns and the team – through their refinement process – had a great feeling of what those meant. And it kept the refinement sessions fun and light – never a bad thing.

Closing Thoughts

It sounds easy and it is compared to some of the mental gymnastics we have to do when talking about points. It does require the same engagement and conversation that happens when you use Planning Poker or some other estimating technique. The benefit is that it doesn’t require pre-selecting a story on size or time (which is questionable). Instead, you start with any story and work through your backlog. And once the team gets familiar with sizing this way, you can introduce points later or keep this method. More tools in your toolkit is never a bad thing.