Mark Needham

Thoughts on Software Development

Agile: Chasing a points total

with 6 comments

I’ve previously written about the danger of using velocity as a goal but on almost every project I’ve worked on at some stage we do actually end up chasing a points total.

Something I find quite interesting towards the end of an iteration is that if there is a choice of two stories to pick up then the project manager will nearly always press for one which can be completed within the remaining time in order to get the points total for that iteration higher.

This might even mean that we pick something which is lower priority because we might not finish a higher priority but larger story in time.

This would mean that the points for that card would not be recognised until the next iteration which would mean that in the current iteration the points total would be lower than expected.

Most of the time this doesn’t make a great amount of difference and if it helps take some pressure off and create an impression of ‘success’ then it seems a reasonable trade off to make.

It does still seem less than ideal to have that type of decision dictated by such a limited metric though.

Dermot pointed me to a blog post by Tim Ross titled ‘Are burndowns evil?‘ where he discusses this in more detail and although I agree with the points Tim makes, it often seems that a product owner ends up with the impression that the project is ‘failing’ or that we are ‘behind’ if the velocity ‘target’ is not being met each iteration.

It seems to take product owners who are new to a more agile approach a bit of time to get used to the idea that achieving the points total isn’t the most important thing to focus on and that it’s more useful to focus on other things which actually give them value.

I’ve worked on projects where we’ve got to the stage where the points total is a side show but it takes quite a bit of time of consistently delivering before we can get that level of trust.

Be Sociable, Share!

Written by Mark Needham

May 11th, 2010 at 10:28 pm

Posted in Agile

Tagged with

  • Pingback: Tweets that mention Agile: Chasing a points total at Mark Needham --

  • Hi Mark,

    [I don’t use burndown or velocity at all but that’s not the point of my comment]

    “This might even mean that we pick something which is lower priority because we might not finish a higher priority but larger story in time.”

    Isn’t this the cost (the evil even) of timeboxing? And completely misguided surely if the sprint doesn’t even end in a release?


  • @Mike – I think you’re right, I hadn’t considered it from that angle.

    Re: iterations

    On the teams I’ve worked on over the past couple of years I’ve rarely seen the value from actually having a time boxed iteration – the only thing it seems to be used for is measuring ‘progress’. I don’t even remember when we’ve changed iteration most of the time.

    What would be the alternative if the product owner still wants a weekly progress type report – would you just report on the state of the story wall rather than completed points in that iteration?

  • I was just talking to Daragh about this today. I’d say talk about the actual stories, not the points. I think points are only impressive for people who don’t actually care what the system does.

    And ideally, switch to measuring lead time rather than points completed.

  • @Mark, as per @Jason, I track lead time without fixing it and I know the number of items actually (or typically) delivered in that time. My key control tool is a CFD, driven by a Kanban board. I describe my process at

    We accept that at any given time there will be work in progress and we don’t get into a situation where less important work gets priority over more important work.


  • We haven’t used points or velocity for about 18 months, instead the team focuses on valuable feature releases – getting those features out and in the hands of users is the most important thing. We don’t bother tracking because we don’t need to, releasing early and often gives the impression we’re making progress, and that’s all that really matters to build trust.

    Recently however, we were staring at some features that were going to take over 2 months to complete, at which point we considered tracking velocity so we could manage expectations. Fortunately, as it happened, we broke the uber feature apart in a few places and we’re able to release early and often again! (It was close…)