Why User Stories Rarely Work

All tools are useful when used appropriately, and User stories are no different.

User stories are fantastic when used in small teams on small projects where the team is co-located and has easy access to customers.

User stories can quickly fall apart under any of the following situations:

  • the team is not small
  • the project is not small
  • the team is not in a single location
  • customers can be accessed in a timely fashion
  • project end date must be computed

AgileManifestoIndividualsUser stories were introduced as a core part of Extreme Programming (XP). Extreme Programming assumes that none of the above are happening; relax any of these constraints and you can end up with a process out of control.  XP, and hence user stories, works in high intensity environments where there are strong feedback loops.

User stories need intense communication 

User stories are a light-weight methodology that facilitates intense interactions between customers and developers and put the emphasis on the creation of code, not documentation.  Their simplicity makes it easy for customers to help write them, but they must be complemented with timely interactions so that issues can be clarified.

Large teams make intense interactions between each pair of developers difficult; intense interactions keep everyone on the same page.  Most organizations break teams into smaller groups where communication is through email or managers — this kills communication and interaction.

Larger projects have non-trivial architectures.  Building non-trivial architecture by only looking at the end user requirements is impossible. This is like only having all the leaves of a tree and thinking you can figure out all the branches and the trunk must be, good luck.

User stories don’t work with teams where intense interaction is not possible.  Teams distributed over multiple locations or time zones do not allow intense interaction.  You are delusional if you think regular conference calls constitute intense interaction.

When emphasis is on the writing of code then it is critical that customers can be accessed in a timely fashion.  If your customers are indirectly accessible through product managers or account representatives every few days then you will end up with tremendous latency.

 

Live weekly demos with customers are necessary to flush out misunderstandings quickly and keep you on the same page

User stories are virtually impossible to estimate. Often, we use user stories because there is a high degree of requirements uncertainty either because the requirements are unknown or it is difficult to get consistent requirements from customers.

Since user stories are difficult to estimate, especially since you don’t know all the requirements, project end dates are impossible to predict with accuracy.

To summarize, intense interactions between customers and developers are critical for user stories to be effective because this does several things:

  • it keeps all the customers and developers on the same page
  • it flushes out misunderstandings as quickly as possible

Diluted

All of the issues listed initially dilute the intensity of communication either between the team members or the developers and customers.  Each issue that increases latency of communication will increase misunderstandings and increase the time it takes to find and remove defects.

So if you have any of the following:

  • Large or distributed teams
  • Project with non-trivial architecture
  • Difficult access to customers
  • Projects in new domains
  • Projects where knowing the end-date is necessary
Then user stories are probably not your best choice of requirements methodology.  At best you may be able to complement your user stories with storyboards, at worst you may need some form of use case.
Other requirements articles:
VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)
VN:F [1.9.22_1171]
Rating: +1 (from 1 vote)

Seriously. The Devil Made me do It!

good vs evilJust as eternal as the cosmic struggle between good and evil is the challenge between our two natures. Religion aside, we have two natures, the part of us that:

  • thinks things through; make good or ethical decisions a.k.a. our angelic nature
  • react immediately; make quick but often wrong decisions a.k.a. our devil nature

Guess God left a bug in our brains so that it emphasizes fast decisions over good / ethical decisions.

Quite often we make sub-optimal or ethically ambiguous decisions under pressure

You decide…


SteamingPileSituation: Your manager comes to you and says that something urgent needs to be fixed right away. Turns out the steaming pile of @#$%$ that you inherited from Bob is malfunctioning again.

Of course Bob created the mess and then conveniently left the company; in fact, the code is so bad that the work-arounds have work-arounds.

Bite the bullet, start re-factoring the program when things goes wrong.  It will take more time up front, but over time the program will become stable.

Find another fast workaround and defer the problem to the future.  Find a good reason why the junior member of the team should inherit this problem.


MultiplePathsSituation: You’ve got a challenging section of code to write and not much time to write it.

Get away from the computer, think things through.  Get input from your peers, maybe they have seen this problem before. Then plan the pathways out and write the code once cleanly. Taking time to plan seems counter intuitive, but it will save time.

Naw, just sit at the keyboard and bang it out already.  How difficult can it be?


BlameSituation: The project is late and you know that your piece is behind schedule.  However, you also know that several other pieces are late as well.

Admit that you are late and that the project can’t finish by the deadline.  Give the project manager and senior managers a chance to make a course correction.

Say that you are on schedule but you are not sure that other people (be vague here) will have their pieces ready on time and it could cause you to become late.


Measurement, smallSituation: You have been asked to estimate how long a critical project will take.  You are only been given a short time to come up with the estimate.

Tell the project manager that getting a proper estimate takes longer than a few hours. Without proper estimates the project is likely to be severely underestimated and this will come back to bite you and the project manager in the @$$.

Tell the project manager exactly the date that senior management wants the project to be finished by.  You know this is what they want to hear, why deal with the problem now? This will become the project manager’s problem when the project is late.


The statistics show that we often don’t listen to our better (angelic?) natures very often. So when push comes to shove and you have to make a sub-optimal or less than ethical decision, just remember:

The devil made you do it!

Run into other common situations, email me

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.22_1171]
Rating: +1 (from 1 vote)