As user stories flow through the whole development process from conception to delivery, they pass through the hands of a number of job functions and workers. Any time that people working in the vicinity of a given work step are given to believe that they "own" the user story in their current purview, they are likely to displace the user story from the most public and most visible medium that is common to the whole team. User stories are often then removed to the bowels of tools that are practical and accessible only to workers at the current work step and its immediate vicinity.
User stories can, do, and should change as they march forward through elaboration from concept to working product. Product development is a process of constantly unearthing a clearer understanding of the work we're doing while we're doing it. No amount of up-front analysis and design can stop this from happening. It's the nature of the kind of work that software development is, ie: product development.
If software development were manufacturing work, we'd know what would be happening in each step of the process before it happened. But then, we'd have to be creating exactly the same product again and again, which would be nothing short of an absurdity for software development.
The further we get into the process of turning an idea into concrete, material product, the greater the clarity and amount of thinking that gets invested into what we're doing. The more thinking invested, the more that we come to understand the subject matter we're working with, the circumstances of product's intended audience, and the fit of the decisions we've made earlier in the process to the reality waiting at the end of the process when real workers will try to do real work with the delivered product.
Analysis and design are present in absolutely every kind of work done in software development, and present in every stage and every work step. And while we may indeed have work steps early in software development processes that appear to be characterized by work exclusively in analysis and design, this is ultimately a consequence of not having concrete product yet in-hand at those early stages.
These early stages are less "Analysis and Design" stages as they are "Absence of Material Product" stages. We resort to seeing early stages as "Analysis and Design" due more to a habit of human perception that tends to draw attention to things that are present than to things that are absent. But later stages are no less "Analysis and Design" stages as a "Testing" stage in any less of a "Development" stage.
It's the same cognitive wrinkle that makes negative space visualizations like Rubin's Vase or the FedEx logo so compelling when we finally recognize the secondary images conveyed by the space that our cognitive facilities filter out. It's also what keeps us from being in a constant state of anxiety due to cognitive overload, and what allows us to be mindful of predators (not to mention to be unmindful of camouflage).
The kinds of work we do in software product development are rarely unique to any given stage. The kinds of work we do accumulates continuously so that later stages have responsibilities for nearly all of the kinds of work done in software development throughout the entire process. That's not to say that front-loading software development work with conceptual work is a bad idea. It's obviously an essential part of doing product development work successfully. But it's easy to mistake early-stage work as the domain of "analysis and design" due to the absence of material product this early in the game. The absence of material product at early stages should be a conspicuous absence, but the conspicuousness is typically lost to cognitive filters.
The disastrous side effect of failing to recognize this negative space perspective is the mistaken conclusion that analysis and design is the sole domain of early-stage work. And it starts the people involved in software work on the slippery slope toward believing that work on requirements analysis only happens early in the process, and that requirements - once defined - will not have to change. As if we could really know anything so conclusive so early in the process of uncovering clarity and understanding.
In the end, early stage work is naturally limited in that it can usually only be conceptual work. Conceptual work is realistically the only work that can be done so early. While the accumulation of responsibilities at work steps later in the process continues, analysis and design never wane. New clarity and new understanding never subsides. In fact, clarity and understanding only get sharper. This continues even once a software product has been made operational.
Because understanding continues to get sharper the further along we are, any concrete record of our understanding must be kept up-to-date to make sure that our collective clarity remains collective. Otherwise, workers at different stages of the whole process will have different understandings of what the goal is - as currently defined by all recent learning.
Making sure that everyone is on the same page is of paramount importance in any development effort. Locking down the definition of what's needed isn't the way to do this - although it's often the mistaken path that software organizations take when they fail to recognize the cumulative nature of understanding and clarity as product development unfolds.
To keep everyone on the same page, user stories must be accessible to everyone involved in a development effort, from early-stage conceptual work, all the way through delivery when placeholders like user stories are replaced with concrete, material product. They must be accessible with the least amount of effort by all people involved and at all stages and work steps.
At any point in the whole process, anyone who is empowered to add user stories, change existing ones, remove user stories, or otherwise make use of them should not have to go through a worker with specialized tool skills due to user stories having been removed to a tool that is not generally-accessible with an absolute minimum of effort and a maximum of immediacy.
Stated as a general principle: No single work group at any work step should remove user stories to a medium that, while more expedient to their work, causes user stories to become less accessible by others with different skills and responsibilities.
The inevitable result of workers at a work step feeling that user stories can be removed to a more locally-optimized medium is that separate copies of a user story will be used by workers at different work steps, and these copies will inevitably diverge. When multiple copies of the same user story diverge, workers at different work steps have different understandings of expectations and goals, and work at cross purposes.
In the worst of these situations, workers at different work steps aren't even aware of the others' divergent versions of the truth, and labor under the resulting conflict without any idea as to why expectations are consistently not being met. This drives up rework, reduces the credibility of the team, increases stress and conflict on the team, and generally leads back to the chaos that Agile development was supposed to address.
And yet, there are indeed advantages to specialized tools for specialized work steps. Great care should be taken though when considering specialized tools for artifacts that aren't specialized. It's often a mistake and an oversight when specialized tools are put in place at a work step that makes collective artifacts less accessible for the duration of the work step, or from that work step onward. In the case of user stories, it's hard to find a single artifact that is more collective, public property and thus less amenable to workstep-specialized tools.
At every stage of development, workers can back-slide into misconceptions of authority over artifacts that are responsible for unifying the whole effort and for stitching diverse workflows and workers together. The further we get into a software process, the more likely it is that workers at a later stage will remove user stories from more generally-accessible media and sequester them into the bowels of tools that are accessible only to people with specialized skills.
For example, consider the Cucumber framework and tools developed in the Ruby community, and the family of derivatives and clones that have since been created in a host of programming languages.
This style of tool encourages the displacement of user stories from more generally-accessible media into programmer-specific media. It doesn't do so accidentally. It's done as a recommended practice - reinforced by articles, books, and software conference presentations and workshops.
While Cucumber is built on some fairly compelling technology, and is itself an impressive work, it's not exactly methodologically-sound in that it fails to recognize its own contradiction of Agile development's core value of individuals and interactions over processes and tools.
As an aside, I brought up this issue with Aslak Hellesøy, the Principal of the Cucumber project, during a trip to Sweden last year. At the time, he informed me that work was being done on a tool to extract user stories from the specialized media to make them generally-accessible. But there are three non-trivial oversights inherent with this solution:
Firstly, it disregards the a-priory value of whole-team organizational methodologies like Agile by allowing collective and communal artifacts that are fundamental to higher-order productivity to become appropriated by one specialization.
Secondly, it seeks to address a problem that exists because of overly-elaborate tooling by creating even more elaborate tooling. The path back to simplicity and clarity - i.e.: "elegance" - likely also suggests removing the first wave of tooling rather than adding a second wave of compensating tooling. There are presently solutions that are arguably more holistically-effective as well as arguably more simple and clear. Although, they're based on less elaborate programming technology, and this is likely why the programming specialization remains distracted for alternatives.
Thirdly, it doesn't address the need to allow user stories to be added, removed, combined, divided, or changed by anyone with the authority to do so regardless of whether he or she is comfortable with tools, approaches, and perspectives that are more natural to the programmer specialization.
A Cucumber-style tool can be justified arguably as a general tool because it serves the whole of the process with testing and specification, but merely serving the whole of the process doesn't atone for the reduction in accessibility and immediacy of collective artifacts.
To Aslak's credit, he demonstrated a way of using Cucumber to me where user stories are not removed to its media. Nonetheless, removing user stories to Cucumber media continues to be a practice that is perpetuated in the user community remains a non-trivial methodological problem that is likely rooted in the narrowing of focus of specialized workers due to impressive tooling.
NOTE: There are more methodological oversights inherent in these tools, but that's a subject for a subsequent article.
Here a some principles to keep in the forefront of your Agile practice amidst the distraction of so many Agile-targeted tools:
1. Individuals and interactions over processes and tools has profound meaning. It doesn't suggest that you shouldn't use tools or processes, but that these often become distractions from more powerful means of ensuring success. Consider tooling choices very carefully - especially specialized tooling. Understand how it might inadvertently narrow the perspectives and values of its users.
2. User stories are a whole team artifact. Any tool that moves user stories to a medium that the whole team doesn't have at their finger tips should only be used when there are no viable alternatives. Forcing some team members to go through other team members to work with collective artifacts is categorically not what is intended by individuals and interactions over processes and tools - even if it does cause people to work together to gain access to resources. These resources are supposed to be generally and immediately accessible to begin with.
3. If you choose to remove collective artifacts to workstep-specific tools, put protocols in-place to ensure discrete hand-offs between tools so that multiple versions of the truth are not available to different workers who work in different work steps. When a user story moves from one system to another, destroy the previous version and leave behind a placeholder - a kind of forwarding address for a user story - that tells the interested party how to find the user story's new home.
4. Don't fool yourself into believing that you'll be able to keep multiple versions of user stories in-sync through the life of a project. This kind of work is too costly to keep up and will be quickly abandoned by the project team, leading straight back to the multiple versions of the truth problems. Adding customized electronic synchronization automation to this problem is also not a good answer. This just adds more elaborateness to a situation that is possibly already too inelegant. It's a problem that likely shouldn't exist in the first place.
The inescapable truth of user story management is that the least-elaborate technology is often the most productive solution - even if the technology is no more elaborate than a ten-foot by five-foot cork board with index cards pinned to it. In the very least, this keeps user stories immediately visible and accessible, and makes changing them no more difficult than putting pen to paper.
Of course, the tried and true cork board and index card solution isn't a good foot for all teams. That said, as you seek more elaborate solutions, take tiny steps forward in settling on your solution. A leaping at the most elaborate solution for user story management usually ends up planting a whole team in a tool that serves the specialized perspective of the people doing the tool selection - often to the disservice of everyone else involved in the whole effort.
It's vital that we're not lured into local optima interpretations like, "individuals and interactions over tools and processes except when the tools are intellectually stimulating". All tools are intellectually stimulating. In many cases, tools can be stimulating to distraction. The problem is what we're being distracted from: the essential root cause of success in software product development. Namely, the magnification of understanding and clarity that comes from interactions between individuals over the course of time. The deeper problem is that we believe ourselves to be impervious to this kind of distraction because we have such positive feelings about our tool choices.
The immediacy and accessibility of user stories is a foundational corner stone that your Agile house is built on. Whether it stands strong and continues to be built upon, or whether it crumbles under its own weight can be decided entirely by this salient factor.
Do everything you can to make sure that user stories continue to belong to everyone, in every minute of every day. And be vigilant against any backsliding into specialized expediencies that remove user stories to any medium that is less immediate or less accessible than the simplest and clearest of tools at our disposal. An elegant solution is often not an elaborate one, but greater whole-team productivity is always more stimulating than elaborate, specialized tools.
Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience
Learn more about my work and how I can help you at ampgt.com
