The learning never stops. Agile re-enforces this and creates the environment to foster it. As an agile coach, the benefit of continuous learning is provided every day.
Last week I conducted a workshop centered on the Product Backlog. The focus was to help engineering understand the purpose, position and power of a properly groomed Product Backlog. In attendance was about 20 people from engineering, engineering management to the VP level and from marketing. The session went well, with several good conversations sparked during and after the meeting.
And, I learned something.
It’s hard to have a Product Backlog discussion without talking about estimating the stories. I was using slides from one of Mike Cohn’s excellent “Agile Estimation and Planning” presentations. The presentation includes a discussion of story points. From previous conversations, I knew the group might have a hard time understanding the concept and value of story points. They are used to trying estimates of real time. Going into the discussion, I was not sure how to show them the value of story points.
We had a break just before the section on story points. Knowing a slide for estimating in “Zoo Points” was coming up, I wrote a chart on the easel in anticipation. The first column I headed with “Animal.” I then solicited volunteers from the early arrivals and put their names on four additional columns. They laughingly questioned what the animal heading was about. I told them to wait and see.
We discussed the concept of a story point and hit the “Zoo Points” slide. Asking everyone to quietly estimate each animal, I wrote the animal list down the first column. Immediately questions were raised as to the scale or criteria that should be used to estimate the animals. I reminded them, while writing the animal list, that story points don’t have units. Some were quite puzzled.
I asked each of the four volunteers to tell me their estimation numbers in turn. All but one provided reasonable numbers of less than ten, even though I had not told them what scale to use. The fourth volunteer gave them all a five, claiming to not understand. That was fine. In discussion, we noted that the scale used and many of the values correlated, even without knowing what each person was using for criteria. I then asked each volunteer what criteria they used, writing their answers at the bottom of their columns. Size, danger, strength, etc. were among the answers.
As I wrote the different criteria, my epiphany occurred. I excitedly stated it to the group as it had formed in my mind:
Unit-less story points allow multiple criteria to be included in the estimate without excluding ANY possible criteria.
If we had started out with a defined list of criteria, the list tends to exclude all other criteria. It narrows and shuts out possibly important input. For example, suppose the Product Owner were to state that estimation must take into account story size, difficulty and performance. A team member will tend to naturally drop other criteria, such as maintainability, domain knowledge, architecture impacts and so on. Unit-less story points make it easier to obtain all the criteria that concern all members of the team.
A secondary epiphany came quickly:
Unit-less story points allow these multiple criteria to be considered and included very efficiently.
The team can discuss all the criteria used by each team member to come up with their estimate. But they don’t have to. Each member could be thinking about completely different concerns, but if they all estimate a “five,” for example, discussion of the concerns is not needed. All the criteria are built into the number without requiring discussion and argument about which concerns are more important.
Combining these values of story points with the efficiency of planning poker, the team can move on to getting more work done. Maybe I should have seen these powerful aspects of story points before. But I didn’t until standing in front of a powerful group, teaching and looking at story points in a new way.
The learning goes on!