One of the clients I’m working with these days is doing a lot of the faux agile things that are frequently mocked in the agile community. Here are a few examples, just relating to the use of story points:

• Story Points are defined as a half day of work. In fact, they have published an internal conversion chart between story points, hours/days, and T-shirt sizes.
• Story point estimates are routinely updated post facto, so that the sprint velocity matches expectation.
• Velocity is calculated per team member.
• Most frequently, tasks are estimated by a person who isn’t actually doing the work.

So, of course I set out to educate the team on all the ways they’re misusing Story Points, and how to improve their estimates, right?

Wrong.

In fact, I haven’t even begun addressing these issues with the team.

Why not?

Well, a couple of reasons.

Perhaps most important: The team doesn’t feel that their (mis)use of story points is a problem. Trying to get them to change this would just frustrate everyone, and waste my time.

But closely related to that: They have other much more pressing issues. And I am helping them with those. Most notably, deploying software is slow and highly unreliable, because the people who set up their infrastructure have left. So I’ve been focusing my efforts on improving their deployment process, with the goal of making it reliable and fast. And perhaps even moving them toward continuous delivery (although they’ve expressed some trepidation in this area… that’s okay.)

The point is: Most teams have many problems that could be fixed. But not all should be fixed. At leat not yet.

I always try to find the biggest pain point, and address that first. Maybe we’ll eventually get to re-defining your use of story points. If that matters at the time.

What pain are you facing, that could use some outside help? Maybe I can assist.