Earlier this year I wrote about some of the problems that we can run into when we have implicit assumptions in stories and another problematic approach I’ve seen around this area is where we end up with stories that are very heavily focused on technical implementation.

Initially this seems like it will work out pretty well since all the developer then needs to do is follow the steps that have been outlined for them but from my experience it seems to create more problems than it solves.

The first problem is that it seems to create a non thinking mindset and the more detail there is the less it feels like you need to think.

This isn’t a great position to end up in since there are frequently multiple ways to solve any problem and we will probably exclude those from our thinking if we’re just following instructions.

As a developer part of the skill-set is knowing how to implement a solution but an equally important part is being able to suggest alternative approaches which may be more appropriate in a given context.

Technically heavy stories only encourage the former as the developer may now assume that any other options have somehow already been considered.

In addition to this it tends to take a lot of time to explain these types of stories which presumably also means that it takes longer to write them up as well.

I’ve also found that it’s more difficult to understand these types of stories since it’s not initially obvious why you need to implement the technical approach that has been described.

Another thing which I hadn’t appreciated until quite recently is that it’s very boring/demotivating to implement stories if all the problems have already been 'solved' before you even start.

Given that it’s somewhat inevitable that we may end up with a story that is shaped like this the key seems to be not to get frustrated by the story but rather to try and find out what the underlying intent of the requirement actually is.