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.