Agile

User Stories are Rarely Appropriate

extreme-programming
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 or project is not small
  • the team is not in a single location
  • customers are hard to access
  • project end date must be relatively fixed

AgileManifestoIndividuals
User stories were introduced as a core part of Extreme Programming (XP). Extreme Programming assumes you have small co-located teams; if you relax (or abandon) any of these constraints and you will probably end up with a process out of control.

XP, and hence user stories, works in high intensity environments where there are strong feedback loops inside the team and with customers:

  • over Processes and Tools
  • Customer Collaboration over Contract Negotiation

User stories need intense intra-team / customer communication to succeed

lightweight-featherUser 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 dilute interactions between developers; infrequence communication leads to a lack of team synchronization. Most organizations break larger teams into smaller groups where communication is primarily via email or managers — this kills communication and interaction.

d1c7d96cfee20ebc131ece1d7862cbdcLarger 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 determine quickly where the branches and the trunk must be.

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; most stand-up calls done via conference degrade into design or defect sessions.

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

TheCountUser 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-300x83

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, i.e. high latency
  • High requirements uncertainty but you need a fixed project end-date

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 light-weight form of use case.

Light-weight use case tutorial:

Other requirements articles:

Reference: User Stories are Rarely Appropriate from our JCG partner Dalip Mahal at the Accelerated Development blog.

Dalip Mahal

Dalip is a principal consultant at Accelerated Development and has worked his way through all aspects of software development. He started as a software engineer and worked his way through engineering and product management.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
Back to top button