Mark Needham

Thoughts on Software Development

Requirements: The story points focus

with 4 comments

Something which an agile approach on a project typically gives us is the ability to change requirements rapidly based on the different types of feedback we typically get over the course of the project.

One way that we can lose this advantage is by getting caught up by the number of story points being completed and using this as the measure of success.

The flexibility to change has an impact on the number of story points that may be completed in a given iteration – if we start doing some work on a story and then get feedback from the business while it is still in progress it’s possible that we will end up with more work to do than we had previously.

Once a story is estimated we don’t typically go back and change that estimate unless there was a change in the assumptions being made before we play it. This means that any changes we make based on feedback would not result in re-estimation of the story card.

We now have more work to do without our measurement mechanism recognising that.

It gets even worse if we start working on a feature and then get feedback from the business that the feature is no longer useful to them and we should just stop working on it.

At this point a fairly common response is to ‘lock down’ the requirements so that we’ll only work on the currently defined requirements and no new ones or changes will be permitted.

While this might make some logical sense it misses the point that we’re supposed to try and deliver something that is actually useful rather than something which just meets the initial requirements.

In reality one of two things, or perhaps a combination of both, ends up happening:

  • There will still be changes and all we’ve done is create the illusion that there won’t be any.
  • The business will now push to get exactly the features that were specified originally even if the development team ends up spending a disproportionate amount of time creating those features for the value they actually provide.

Story points are really useful for allowing us to get an idea of the relative size of stories and can be helpful for getting a rough understanding of the amount of work we can complete in a given time period but we need to be careful how we use them.

Our goal at the end of the day is to deliver working software.

Story points are just a mechanism for giving us some feedback on how well we are doing that. They’re not the goal in itself.

Be Sociable, Share!

Written by Mark Needham

November 23rd, 2009 at 11:46 am

Posted in Agile

Tagged with ,

  • Pingback: Story points and Estimation « Dahlia Bock()

  • Pingback: Tweets that mention Requirements: The story points focus at Mark Needham --

  • Great points Mark. The main reason for using story points, aside from the fact that almost no one can be 100% accurate with hour estimates, is as you say to provide a rough estimate of the size of a task. Velocity tells us how much “stuff” we might finish in a given time period. However, velocity is not the end all to be all of measurements. It’s merely an other planning tool. Regardless of how we estimate stories, the end game is to deliver value to the business and our customers. That is the true measure of any team, and any company.

  • Hey Mark!
    You are more than right mate!
    People miss this point sometimes.. And they try to aim for points…
    I always like to remind about one of the Agile Principles that you pointed as well:

    “Working software is the primary measure of progress.”

    In your words:

    “Our goal at the end of the day is to deliver working software.”

    C u mate!