It can be easy to get carried away with implementing a feature. In our minds, we know exactly how it should work. We know what pieces go where, how it should look and how it should behave… or at least we think we do.

Okay, so maybe most of the time we have a pretty good idea of what the end result should look like, but we don’t have time to complete the entire feature. We lost track of time, and we’re missing a critical component.

It can be tempting to hunker down and try to complete everything we think it should have, but is this really the best strategy? Instead, we should take a look at the acceptance criteria of the feature–what is the minimum amount of work needed to satisfy this criteria?

In the Agile Manifesto, the tenth principle is this:

Simplicity--the art of maximizing the amount
of work not done--is essential.

I’m pretty sure this is referring to avoiding the smell of needless complexity in our code, but it’s something to think about when it comes to project features.

Why wouldn’t we want to implement the rest of this feature? Well, the first reason is that we just don’t have time. It’s either going to be missing altogether when meeting with the client, or it would have been coded under immense pressure with no time for proof-reading and refactoring.

Another reason we’d want to stick to the “minimum amount of work” rule here is that maybe, when you present the product, the client sees it and decides to go a completely different direction. If you had decided to complete a week’s worth of work in two days, it all would have been for nothing!

Save yourself the stress and the trouble–if it’s not in the acceptance criteria, shelf it for later on in the project when you have some time to kill.