fbpx  

Archives for Feb,2019

You are browsing the site archives by date.

It’s Time to Deprecate Story Points

It has been known for quite some time in the agile community that estimation is waste.  And yet, I still see many, many teams spend huge amounts of time in story pointing sessions.  I’ve experienced people passionately debate whether a user story is 3 points or 5 points.  If that isn’t a waste of time, I don’t know what is.

I’ve stumbled across a pattern over the last 5 years or so that has probably always been there, but, hey, sometimes I’m a little slow (and, I’m not the only who’s noticed this by the way).  When I first noticed it, I was a little surprised.  Once I noticed it, I saw it everywhere.  But it made complete sense.

When estimating with story points, the purpose is to determine a velocity (total number of story points completed in a sprint) so that you could estimate how much a team can deliver within some period of time.  I was a big believer in this…it really worked.  It helped us be able to say “no” to more work during a sprint.  Drawing that line in the sand was awesome as we had real data to know where to draw that line.

While teams discover their velocity in points, I thought I would see how velocity correlated to number of user stories completed.  And then I found the pattern.  Teams consistently not only delivered approximately the same number of story points during a sprint, they also delivered approximately the same quantity of stories.  When I first discovered this, the team I was working with consistently delivered between 9-11 user stories every sprint.  I went back at least 5 sprints, and it was always the same.  I thought maybe that was a fluke.  So, I looked at other team’s (on the same initiative) product backlogs.  The same thing.  Consistent number of stories every sprint.  

Afterwards, when I worked with other teams, I noticed the same thing.  It’s extremely consistent.  And it made complete sense.  When you decompose user stories to the point where they fit into a sprint, you will find that some stories you thought were tiny are a little bigger, and vice versa.  Ultimately, it “comes out in the wash”. 

I do have one caveat.  If, for some reason, your team(s) have a tough time decomposing stories and the size of them vary wildly, then this may not work so well.  However, instead of trying to estimate better, you should put your efforts into learning how to decompose your work into smaller batches.  There will be a much bigger payoff.

Having experienced the widespread and consistent pattern, maybe it’s time to deprecate story points.  I know what you’re thinking, “what about long-term planning?”.  Long term planning smells like waterfall.  However, it is completely reasonable when a customer asks, “when do you think this will be done?” or “how much can you complete by October?”.  Ultimately the answer is always “we’re not sure”, but that doesn’t always fly.  There are other ways to provide a target (or a guesstimate).  But, alas, I’ll leave that for another post!

What do you think?  Is it time to deprecate story points?

Create Agile Leaders First

Agile has been around for quite some time now. The big dogs, Scrum and Extreme Programming, have been around since the late 90’s, just a little over 20 years! Wow how time flies.

I’ve been teaching classes on Agile for quite some time now…just a little over 10 years. Early on, it was really just a Scrum class, but over the years it has evolved quite a bit to include Lean, Kanban, Extreme Programming, etc. depending on what is best for the organization.

Most of the time when I teach classes it’s for a company that’s already started their agile journey, as most claim they have. So going into each class I have some assumptions, primarily that management has a basic understanding of agile and understand their role in the transition. I also assume that the teams have some rudimentary understanding of the basic principles of agile.

However, during the classes I typically hear these kinds of comments/questions throughout.

  • Our Scrum Master is on at least 5 other projects.
  • We don’t have a Product Owner.
  • We have to track our time on every story, how do we do that in Jira?
  • We spend about 3 months creating a requirements document. Why do we need a Product Backlog?
  • QA is on a different team.
  • Management won’t let us add new stories until it goes to the change review board.

And the list goes on an on. Obviously they either started off on the wrong foot or they have lost their way.

How can we avoid this? Or, how can we course correct? The magic ingredient is to create agile leaders first, before you create agile teams. The best way to kill an agile transition is to ignore the role management must play.

Now, this isn’t an all or nothing proposition. I’m not saying “every manager must become an agile leader in this entire organization before we start working with the teams”. Heaven forbid. We need to approach the agile transition in an agile way of course! For example, if a specific division is chosen to start the journey, let’s begin by having some workshops and coaching with management in that division first, then we will weave in the teams. If you start with the teams while ignoring management, and tell the teams to “go forth and be agile”, management will not understand their role and will unintentionally become impediments. That’s where you get all the “Agile Sucks!” rants online.

Now, if a company approaches me for training to “make their development teams agile”, I let them know that they must start with management. I also let them know that training alone is not enough. Ignoring these two things almost guarantees failure.

So, what do you think? Should we start with creating agile leaders first or is it okay just to train up the teams, ignore management and call it a day? I’d love to hear your thoughts!

post =