Before the User Story and the Unknown Value Stream…
The User Story is the defacto “widget” of requirements for agile teams, the unit of work that teams are measured by. Technically, writing the user story is straightforward if you follow the best practices of form as outlined in the three 3cs; Cards, Conversation, and Confirmation. These are essential components for writing a good User Story. The Card, Conversation, and Confirmation model was introduced by Ron Jefferies in 2001 for Extreme Programming (XP).
The Card part of the 3Cs defines the 3 part format of the User Story, (As a ‘role’ I want ‘a goal’ so that ‘I benefit’). So following the format and adding conversation and confirmation should get you a GREAT user story, right?
Not necessarily.
Corporate spend is greatest BEFORE the User Story
While tons of time, money and research goes into improving development and software engineering tools to make coding faster and better (which is a good thing), the real problem is BEFORE coding starts.
Before hundreds or even one User Story can be written, a business needs a good enough starting point to understand what it wants its software to do and how it is to do it. We are not talking about trying to know everything up front regarding requirements or design. That is the Waterfall methodology which was tried and deemed problematic by the industry.
A business needs to ask the question, how fast can our body of knowledge (requirements and design) that supports contextually meaningful user story authorship and refinement coalesce to a critical mass?
If you can shorten the time to that critical mass then software development can start sooner rather than later.
Meta-Story and the before pipeline…
The User Story and its de facto form (As a ‘role’ I want ‘a goal’ so that ‘I benefit’) in agile development requires additional contextual information for developers to effectively build and test code. While the card and conversation elements of a single user story does provide local context, it does not provide a broader systemic context. Human developers crave context. They need to fit the user story in a broader “meta-story.” When human developers have the “meta-story” and user stories together, this leads to improved shared understandings which aligns code with intent and better development outcomes.
Most businesses write requirements using a variety of forms and formats, their artifacts. It is in these requirements artifacts where the “meta-story” emerges. This is necessary and important. The “meta-story” is a narrative about what is being planned, why it is needed and how it will be executed.
To build this narrative, many types of requirements artifacts may or could be used including (not an exhaustive list): project charters, project summaries, vision and mission statements, roadmaps, release plans, business cases, lean business cases, business canvas, lean business canvas, business requirements documents, architecture overviews, technical design specifications, technical designs, data models (logical and physical), data dictionaries, scope summaries, lean business cases, epic hypothesis statements, roadmaps, wireframes, class models, business rules, state diagrams, workflows, story boards, journey maps, personas, and empathy maps. These types have emerged over time to address different challenges in the midst of a shared understanding.
These different types provide varying modalities for information presentation and consumption. It meets the needs of different organizational cultures as they deal with planning and execution. Regardless of which types are used they are part of a requirements pipeline whose end goal is production of business scope and eventually user stories.
The Requirements Pipeline: The unknown value stream
In the illustration above, the oil and gasoline refinement pipeline illustrate the engineering process that produces the fuel for our cars, trucks, planes, trains and other fossil fuel engines. From ground oil extraction to collection to transport to chemical refinement to the gas pumps.
In software development, the Requirements Pipeline is a sequence of knowledge worker steps and activities that involve people and processes who end product is the “before the user story” scope.
This Requirements Pipeline is also an unknown or unidentified value stream.
Few organizations recognize that they have a pipeline or even call it that. All they know is they have to somehow tell software development partners what to build. It is then up to them to create features and user stories to support their build.
Map your Requirements Pipeline Value Stream to find delays and accelerate the speed of Scope
Value stream mapping is a proven analytical technique. Applying this technique to your unknown requirements pipeline can yield crucial information about delays in the scope formation process. It allows an organization to know more about the BEFORE of the User Story.
In the next blog post, we will illustrate a value steam mapping of a requirements pipeline and what a business can do to accelerate its speed of scope.
To know more checkout these resources…
- Author’s book on Amazon, Incremental Readiness Requirements
- Free Solo Plus One Subscription to Agile Ready, the User Story Rating Platform for Agile Product Requirements Readiness https://beagileready.com/subscription
- Author’s Website http://tonytimbol.com/
