Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 548 posts at DZone. You can read more from them at their website. View Full User Profile

Technical Implementation Heavy Stories

12.14.2010
| 3684 views |
  • submit to reddit
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.

From http://www.markhneedham.com/blog/2010/12/13/technical-implementation-heavy-stories

Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)