Most IT professionals are taught to think in terms of what a software system does or the functionality it presents to users rather than in terms of the business or mission outcomes users want to achieve. We see this first in the way requirements are written. In traditional software projects (i.e., Waterfall), requirements analysts and/or technical contributors write requirements from the perspective of the system. For example:
The system shall allow users to upload xyz reports
We could further refine and decompose this requirement (e.g., bulk uploads, user access (user interface or drop folder)) but the point here is that this traditional style of writing requirements puts the system front and center. On its own, this requirement provides no context to inform decisions about how best to implement this upload capability. The intent behind the need for an upload capability is missing.
This shortfall is typically addressed with additional requirements and documentation (e.g., CONOPs, design documents). Unfortunately, documentation is a poor way of communicating the business or mission context necessary to align proposed functionality and solutions to customer and end user needs.
User stories were supposed to fix this. After all, the most popular user story template places the user front and center:
As <a user or role> I want <some capability> so that <desired outcome>
So, we can re-write the requirement above as:
As a payroll analyst, I want to upload xyz reports so that I don’t have to manually input their contents.
We now know who needs the upload capability and for what purpose. The role of the user is important because it alludes to the kind of data we are talking about: payroll data. The outcome lets us know that the system is expected to do something with xyz report data, so this is not just an archival function. User stories are meant to be reminders of further conversations about what is needed, and this user story identifies the user to talk to, what they need, and why. This is enough information to get the conversation started.
More often than not, however, I see user stories written like traditional requirements:
As a system, I need to provide a way to upload xyz files.
Or worse:
As a developer, I need to build an xyz report upload capability.
The first example jettisons Agile user-centricity out the window in favor of a focusing on what the system will do. The second example makes it all about what the developer needs to do, thus making it a task, not a requirement.
So, what is the harm in all of this if the work gets done?
Click here for a more in-depth explanation of how to write user stories.
Bad User Stories Lead to Bad Value Delivery
Agile value delivery is primarily feature-based while traditional software development is component-based.
Features are cohesive and complete slices of system functionality capable of performing useful work from the perspective of customers and end users. Agile projects deliver system scope iteratively and incrementally as features. A feature does not necessarily need to be user-facing. For example, client systems that communicate with a back-end service are that service’s customers.
One way to visualize how to slice system scope into features is the “Layered Cake” analogy. Like a layered cake, systems have multiple layers. The layers represented here make up a typical three-tiered web architecture where the bottom represents a datastore or database, the middle tier represents some kind of middleware, and the top layer represents a user interface. The entire cake represents the scope of the complete system.
In a traditional project, you either get the whole cake at once or none at all. In Agile, we deliver slices of the cake. The customer consumes the cake a little at a time until they finish the cake.
Each slice of the cake or feature contains enough functionality from the three tiers to serve as a valuable feature. Every slice works with the slices baked before. The full scope of the system is defined, developed, and delivered “a slice at a time”. An increment is the sum total of all the slices or features delivered along the way. Thus, Agile development is iterative and incremental.
This analogy is overly simplistic since Agile teams do not slice features from a finished system. Instead they bake the cake one slice at a time. Along the way, the customer tells them what changes to the recipe they would like made. Also, we don’t know what the cake will look or taste like at the end. The customer may decide half way through baking that they have had enough or ask for more.
User stories are essentially features. A user story is a placeholder for a slice of system capability that can be delivered as a cohesive whole, integrated into the emerging system, and that delivers valuable business or mission capability. As we learn more about what is needed and the relative level of effort required to implement them, we refine, decompose, and size user stories. However, no matter the size, every user story represents a valuable business or mission capability.
Traditional requirements are aligned with how traditional software projects track and organize work. Requirements are allocated to system components that satisfy the requirement. This leads to the development, verification, and validation of individual system components. As a result, customers and end users must wait until enough system components are finished and integrated together into a cohesive system to deliver anything valuable, from a business or mission perspective. In traditional projects, this can take months or years.
This is important because the longer we wait to deliver useful capability to customers and end users, the later it will be before they can validate assumptions behind what we develop. Finding out that the solution is not what is needed or wanted at the end of a project is an unacceptable, yet common, occurrence in systems development. The faster and more frequently teams release functionality, the more opportunities we gain to incorporate what we learn into solutions as they are developed.
Conclusion
Agile-based approaches in general, and Scrum specifically, are ways of working that are based on a small set of principles. Take away any of those principles and you are no longer practicing an Agile approach. Agile is a user-centric approach to software development. Taking away user-centricity shifts the focus from frequent delivery of valuable business or mission capabilities to customers and end users to delivery of a finished system. Something as simple as how we write user stories is indicative of how well we have internalized Agile principles and understand the rationales behind Agile practices.
Have you seen examples of bad user stories like the ones covered in this article? What interesting examples of good or bad user stories have you seen? Tell us about your experiences here.