DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > Technical Implementation Heavy Stories

Technical Implementation Heavy Stories

Mark Needham user avatar by
Mark Needham
·
Dec. 14, 10 · Java Zone · Interview
Like (0)
Save
Tweet
4.26K Views

Join the DZone community and get the full member experience.

Join For Free
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

Implementation

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • JIT Compilation of SQL in NoSQL
  • Event-Driven Microservices?
  • Is NoOps the End of DevOps?
  • Build a Data Pipeline on AWS With Kafka, Kafka Connect, and DynamoDB

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo