Story Points are Only for the Team

One manager says to the other…

My team’s doing an amazing job, in 9 months we’ve increased our velocity from 28 points per sprint to 65 by changing our development practices and adopting XP.

Now we do TDD, pair programming and relentless refactoring. Better still, we have story kick-offs and the team swarms around a single story until it’s complete. We all do the scrum-ban can-can to get ready-ready for done-done…

That’s nothing says the other manager, we’ve just increased our velocity by 1000% in one sprint with only one change to our practices!

 

 

We added 3 extra zeroes to every story point estimate.

Believe it or not, this really does happen in some organizations although usually much less extreme and obvious. Story point inflation becomes more common when velocities are compared either across teams or reported through management.

Q: What’s the best way of increasing a team’s velocity?

A: Use it as an external performance measurement.

The same issue holds true for the total number of stories completed.

Q: How do you make your teams complete more stories?

A: Make stories smaller.

It’s a a well-known fallacy that using story points for anything other than a team’s own diagnostic for tracking their progress towards a goal is risky.

Also bear in mind that if you’re using velocity and story points the way many of us have been taught then you’ll be using historic averages rather than ranges. If you examine the probability curves of historic averages, there’s a strong possibility you’ll only hit that forecast velocity 50% of the time. (I’ll expand on this in a more detailed article on estimation)

Do not confuse story points with being anything other than an internal diagnostic to the team and don’t confuse numbers and “data” with meaningful feedback.

If you want to measure the delivery success of the team, focus on what was actually delivered.

Ask stakeholders and customers for feedback – frequently.

Try a simple Net Promoter Score style survey or even better, be lean and “go see”. If you can’t go see, get a video testimonial from the “customer”, play it back to the team and the management.

It’s a lot harder to distort the meaning of a recorded conversation than metrics.

Share
avatar

About The Captain

Captain Crom started programming and debugging games from magazines on his Brother’s BBC as a small boy in the early 1980s. With early qualifications in both computer science & art and a love of live music it became clear he was destined for bad things. His tyrannical ways commenced with a degree in Computing & Informatics at Plymouth and from the mid 1990's a career in the software industry. After formative years as "The Scourge of the Thames Valley" between Reading and Bracknell with occasional raids on the San Francisco Bay area, since 2004 he has been seen sailing stretches of the A10 North and South of the Isle of Ely with the primary source of his raids targeted around Cambridge. Sightings have also been rumored as far afield as Scotland, Norway, India, Nevada, Florida and Georgia. The Captain has served in companies ranging from successful startups and ailing dot-coms to global corporations, spanning roles from IT, consulting, support, development and management through to agile coaching. The common thread in each of his roles is that he has always chosen to join software product groups - usually large-scale enterprise software. His large-scale product and organizational focus differentiates him from the more common textbook agile captains. (Other differentiators include his distinctive hoop earrings and love of spiced rum) The Captain's Agile experience started with a blend of FDD and XP in what he describes as "the most disciplined team he had ever served with". He subsequently moved onto using Scrum and XP blended with Theory Of Constraints, Kanban and Lean philosophies to improve software delivery techniques in other organizations. He believes every member of a delivery team should spend time with customers supporting the product they produced. “Sitting at the dirty end of a product (or cutlass) completely changes the way you think about business processes and write software for the rest of your softwarefaring career!”
This entry was posted in Musings. Bookmark the permalink.

One Response to Story Points are Only for the Team

  1. Amen to that :-)

    I’m going to do a follow up on this article, so important that businesses truely understand velocity and estimations better.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>