As soon as someone gives analytical minds a number and a way to produce that number, we naturally go to work digging into its meaning. Analysis is fine when it leads to beneficial results. Many times such research leads to wasted time at best and damaging side effects at worst. Some examples:

• Velocity was average last sprint. We know we can do better so let’s push this sprint to get +10 on that number!
• The VP says she’ll take us out to the movies if we can increase our velocity by 25% this iteration.
• Team Tiger completed 30 points last sprint and we only got 23. We need to do better than them!

Before we look at these examples further, let’s take a road trip.

Driving Velocity

I live in the Phoenix, Arizona, USA metro area. Because my wife (especially) and I enjoy a famous rodent’s home in southern California, we’ve often made the 350 mile drive to that neighboring state. We know the route fairly well.  We also know that sometimes traffic, detours or other things might interfere with our usual progress.

When we arrive at the hotel our conversations about the trip never sound like:

• We averaged about 62 miles per hour this time. We know we can do better so let’s push to get +10 on that number on the way back!
• Mom says she’ll buy us extra churros if we can bump our speed average by 25% next time we come.
• My buddy Harvey drives at 80 miles per hour on this same route and we only do around 70. We need to do better than Harvey next time!

Do you talk about velocity like that after a road trip? Why not? Because the velocity is not what we are should be delivering. Let’s read that again.

Velocity is not what we are delivering.

On a road trip we are delivering a destination by a more or less certain time. While driving, velocity is important in the moment of driving, in consideration of safety and to avoid speeding tickets. No one cares if we could have gone 78 miles per hour instead of 74 in the stretch between Tonopah and Quartzite once we are in view of an artificial Matterhorn mountain!

Velocity Used Well

The three bad examples I started with all use past velocity and even some other team’s velocity. They all center the conversation around velocity, as if customers want more and more story points! Customers want working software and everything we do should be in support of delivering working software, not velocity.

I promise, if managers ask teams to deliver velocity, they will.  Most likely by cutting quality or simply increasing the scale of work size estimates, which has little to do with delivering more product.  So use velocity as an indicator, as it is used in driving.

• The team velocity now is an indicator of how much work can be done in the next sprint.
• Velocity is an indicator of what will be included within the current series of iterations making up the release.
• Velocity highlights that something is going really well or needs improvement. The improvement doesn’t come by raising velocity, it comes by making the improvement.

Let’s revisit our statements one more time, where velocity plays a part but is not the focus.

• Velocity was average last sprint. Why didn’t our new unit-test framework give us the boost we expected?
• The VP says she’ll take us out to the movies if we can get that video feature done this iteration.
• Team Tiger delivered all their stories last sprint. We need to ask them what is working so well!

There is so much more to say about velocity and how to use it. Please keep in mind the possible negative effects when we take our eyes of the product and start seeking credit for a number. And remember to deliver working software, a product, customer value, not points!

One team I’m coaching had members with varying degrees of concern about estimating in story points.  The team had difficulty embracing story points instead of units of time because units of time matched their past experience.  We defined “ideal days” for estimation purposes.  An Ideal Day for our team was defined as 6 productive hours in an 8-hour workday.  The team would define a task for a specific team member who would estimate its work in ideal days.  They could determine how many features to include in a sprint by adding up the estimated ideal days against the length of the sprint.

This approach was pretty good:  The team was able to start using Scrum, plan sprints, use a task board and make serious progress.  Those are big benefits!

Some sprints later we began to notice some negative effects to this approach:

• We were still using time as the basis for estimates even though humans are better at relative size estimates.
• We were writing each tasks with a single, specific person in mind.  This contributed to a perpetuation of engineers going off in a corner to do “their piece” alone.
• To some extent, the tasks, and the availability of specific people to do them, were driving the order of the features implemented, instead of value driving the priorities.

Last retrospective the team pointed out that we were not meeting our goals.  We determined that part of this was the desire to make sure all the ideal days were booked with tasks for every team member.  This caused the focus of our tasks to be far too broad.  We noted many times where someone in the Daily Scrum would report an impediment because some other person had not completed their task.  The words “tracking dependencies” and “critical path” even came up!

In the time between the retrospective and the sprint planning meeting, I conferred with a colleague ScrumMaster about the retrospective.  He drew a one sprint long, mini Gantt chart (Gasp!) on the board showing the separate tasks for one hypothetical feature.   We could see that many times integration of individual’s pieces does not happen till late in the sprint, sometimes too late to expect it to work.  We realized that the focus on tasks was completely de-emphasizing delivery of the stories by the whole team.

Thirty minutes later we began the sprint planning meeting with the following proposed shift in the team’s work agreement:

• Don’t explicitly estimate individual tasks except when needed to clarify them further.
• Don’t explicitly assign a person to individual tasks.
• Do use stories that can be completed within the sprint.
• Do estimate the stories by difficulty, size, risk, etc. relative to each other using story points.
• Do have team members self-assign to each story so they will work together to get that story done.
• Do continue to work on the assigned story even if “your part” is done.
• Do support other stories in the sprint if you have time available.
• Do add or remove tasks as needed to get the story complete by the end of the sprint.
• Do track sprint progress on the burndown chart using the story points of completed stories.

We originally started this team by focusing on estimated tasks.  This got us going in the right direction but, after several sprints, helped push us into old ways.  Separate people waiting on each other is not a team.  Now we have a story focus with the understanding that the tasks are only important as long as the story gets done.

Work the story, not the tasks!  We’ll see how it works for us.  If the team board looks like this at the end of the sprint, it’ll be a success.

http://www.flickr.com/photos/dinomite/ / CC BY-SA 2.0

(I have been looking around the web while thinking and writing about this blog post.  Seems some teams and well known agile leaders don’t agree about estimating only tasks or only stories or both.  For example, Mike Cohn recommends story points for release and backlog planning but time on tasks for sprint planning.  Well, inspect and adapt is the agile way.  We tried only estimating time on tasks for a while and think we don’t like it.  This switch to story points may be what we need.  Or we’ll adapt again later.)

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.

The resulting "Zoo Points" table

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!