Velocity, Acceleration, and “The Jolt”

Lean-Agile owes a great deal to quantum physics, behavioral economics, and the Toyota Production System. It should not be surprising when our language about teams, programs, and value streams find themselves caught between the science of lean-agile and the metaphors of organic systems.

The metaphor side is crucial, because spoken language is processed by the emotional “side” of brain, while critical thinking and logic is processed by the cognitive “side” of the brain. Especially in a context of uncertainty and optimism toward innovation, the ability to inspire critical thinking through appeals to emotion and narrative becomes essential.

Lean-Agile Art & Science

The metaphors are easy to spot: release trains, delivery pipelines, product portfolios, architectural runways, branches, and streams. These are highly useful for an emotional connection of highly complex cognitive issues, because it is easier to imagine a tree, an airport, or a morning commute than it is to imagine vectors, superposition, and wave functions. The poetry of lean-agile is crucial to learning.

Simply: The art of transformation is the science of The Jolt.

The scientific language of lean-agile is also easy to find, because the burden of proof in any transformation effort is placed fairly and squarely on the shoulders of the system builder who wants to move from periodic marginal utility to long-run economic optimization.

The science begins rather simply. We move from Newtonian laws (hours, dollars, dates, and ROI) to Einstein and Quantum Physics (relative size, value creation, continuous delivery, and probability). Along the way we begin discussing velocity, process control, production systems, and acceleration.

There is a small problem, however. While the science of lean-agile relies on cognition and learning, one scientific construct lies in the realm of emotion and personality:

The Jolt.

The physics are not hard to summarize, but they tend to work for us only in hindsight, in a retrospective moment of privilege. Treated like a particle, a system with position and without momentum is a point. With momentum (mass that is in motion), it becomes a vector. We call the change in position over time velocity. When we want to guide the velocity to an improved velocity, we must act upon it from the outside to cause acceleration. Velocity is the derivative of position (a line). Acceleration is the derivative of velocity (a curve). The Jolt is the derivative of Acceleration, when an external force accelerates acceleration. Lean-Agile transformation is the art of causing The Jolt.

Transformation is the art of causing The Jolt.

While the science of Lean-Agile deals with velocity and acceleration, average completion and standard deviations, plotted on charts and easily analyzed using the Nelson Rules, probability theory, and behavioral economics, the art of transformation lies in cultivating a simultaneous Jolt for the enterprise as an engineered complex adaptive system of systems.

Like any of the great story-tellers of history, our Scrum Masters, Agile Coaches, Program Consultants, and Solution Train Engineers play an essential role in crafting the narrative that inspires changes in acceleration. Such narratives must restore the humanity of our workers, because the postmodern era has decentralized the alienation of labor – today more than ever, we alienate ourselves from our essence and its labor in ways no system ever could.

So the Art of The Jolt can take many strange forms, counter-intuitive to the development of a culture of innovation prior to its existence precisely because the naïve organization sees optimism, hope, and effort as simultaneously extrinsically and intrinsically rewarding. As philosopher Alain de Botton emphasizes, such optimism is the source of all rage in society. It should be no wonder that lean-agile efforts predicated upon optimism often die on the vine due to the rage of its sponsors.

Crisis, tragedy, alienation, loss, and pain are common among all of us. Confusion, separation, fear, and anxiety are integral to the human experience. Is it any wonder that the tendency of firms toward homogeneity (Oliver 1997) is simultaneously the alienation of all heterogeneous sentiment? Thus, to advance as a manager requires suppression of such feelings except as political economy, but to advance the transformation as a system of adaptive systems builder requires existential psychoanalysis, enough tragic story-telling, vulnerability, and authentic emotion to finally Jolt the rigidity of the system toward a new valence and equilibrium narrative (Hoff & Stiglitz).

How does The Jolt happen?

We visualize work based on totems, cards, and digital boxes meant to represent relative size. The weight of ideas we have not tested must be felt or we never develop the discipline to conclude. Information capital requires we shift the view of information inventory – there is immense cost to holding onto knowledge without market validation, even though traditional cost accounting cannot see or audit it. Again, metaphor prevails, because sticky notes are a totem for pain previously suppressed out of optimism – we may use imagery like rusting mechanical assembly parts and pieces in a warehouse due to overproduction and bullwhip effect. The critical Jolt is artistic and emotional, and it force the system to recognize how much cost and pain is being hidden on hard drives and cloud servers.

We can then trace lines of completion and progress, burn down charts and cumulative flow diagrams, to show that no matter how much pain we find in the world, our sanity is predicated on the rate at which we heal, not the rage with which we retaliate. We put on display our average rate of forgiveness, altruism, and cooperation, because the best way to alleviate individual selfishness is to treat family-system anxiety.

Next we fight for continuous funding, because learning is impossible in a state of anxiety. Well-formed teams create a support network for experimentation, the freedom to fail together, express our fears, take the time to understand and forgive the shortcomings of compatriots, and mourn our losses. The team must be large enough to make it clear that we are not alone in our pain and anxiety, but small enough that our relative exposure to new experiences can be felt personally despite the support of the group. So Retrospectives start as outward-blaming complaint sessions and do so with good reason – the supply-side person in pain has onto their rage at disappointed optimism and betrayal of promises with no demand-side action to listen systematically.

Retrospectives then mature over time, and the Scrum Master (or corollary role) must shift between therapist to the individual and therapist to the team. First is the need to convince each person’s pain and anxiety should not be alienating, but that it is human to feel lost and hopeless. Next is the process breaking apart intrinsic worth from external valuation – without anyone being responsible, the system and the individual arrive presenting symptoms of co-dependency. Then, the group is taught in isolation from their system how to forgive, relate, and reach out to others who are equally scared, anxious, and in need of help.

Only then can healthier mental schemas be taught – external forces that appear outside of our control can and should be mitigated and accounted for, every rule has exceptions and those processes are worked through to ensure adaptive behavior, functional “family”-system interaction, and long-run inter-personal resilience.

Finally, the team can harness the energy of the market, understanding that innovation is a process of solving for pains in better ways than before (Svare 2014). The discipline of stoicism and scientific method finally keeps optimism focused on learning to ask more intelligent questions rather than feeding the enterprise’s prototypical, pervasive, and ongoing gambling addiction, betting big on technical hype rather than sustainable growth.

Essential to all of this is the ability to tell personal stories of disappointed hope, fortune wiped away by mere chance, fear of loss, anxiety toward being good, strong, and brilliant enough not only for ourselves but for our network, families, and legacy. If we run out of stories of our own, of course, fiction has always been the best place to find the stories of tragedy we need in our times of greatest optimism and reciprocal anxiety – Oedipus, Socrates, Othello, Madame Bovary, and The Jungle, along with a slew of tragic film stories should give us more than enough stories when our failed products, projects, relationships, and companies leave our audience wanting more.

Conclusion

The art of transformation lies in The Jolt, one that must reverberate through every level of the system in the form of tragedy and emotional re-connection. It is only in such somber moments we can let down our walls enough to reflect, exposed to our own alienation and disappointment, about what we are part of, how little we have changed, and how slowly our hopes are achieved. Only then can the system as a whole take the decisive shift into a new stage of transformation economics.

Do not wait to tell your story – someone, somewhere, less strong, less courageous, or less willing to risk humiliation is out there, and they desperately need you to let them know that none of us are alone.

Sources Cited

Hoff, K., & Stiglitz, J. (2016, 6). Striving for balance in economics: Towards a theory of the social determination of behavior. Journal of Economic Behavior & Organization, 126, 25-57.

Johnson, B., & Hernandez, A. (2016). Exploring Engineered Complex Adaptive Systems of Systems. Procedia Computer Science, 95, 58-65.

Oliver, C. (1997). Sustainable competitive advantage: combining institutional and resource-based views. Strategic Management Journal, 18(9), 697-713.

Svare, H. (2016, 6). User-Producer Dialogue, Workplace Innovation, and Knowledge in a Regional Innovation System. Journal of the Knowledge Economy, 7(2), 565-586.

Minimum Viable Hyperorganism

 

Excerpt from Andrew Keener’s upcoming book: Continuous Experimentation 

Our definition of a physical “organism” is closely related to our definition of “living” itself. From a single-celled plankton to the human body, the ability to maintain cohesion, protect a semi-permeable boundary between self and environment, sustain its own existence, and reproduce are the difference between a complex system and living system.  Our understanding of an organism is tied to what it means to act as a minimum viable living system, regardless of the subsystems necessary to reproduce this “atomic” sovereignty.

Because we want to apply this organic scaling strategy to our socioeconomic systems, we can now ask a much harder question – how do we create a complex adaptive system, made up of human workers, ideological and socioeconomic constructs, machines, and information systems that can maintain their long-run viability. In other words, how can we use Organic Leadership to build a corporation, nation, or global economy that cannot die? We have seen throughout history many nations – and several empires – rise and fall, economic systems falter and crumble, and multiple millions of for-profit ventures fail to survive. If such constructs are the essential scaling pattern of human socioeconomic behavior, how do we create one that can come alive, and survive eternally?

We are creating an entirely new construct, then.  Just as a tesseract represents the construct of a fourth-dimensional cube – a “hypercube” what we are defining is a socioeconomic construct that is not merely considered a legal entity, it comes to life and does not die (for a very long time). We will call this construct a hyperorganism.

A hyperorganism is a quasi-eternal system and we establish our corporations as a legal entity that perpetually exists. Some of today’s corporations are very likely to evolve into the first hyperorganisms. A hyperorganism is made up of human workers, ideological and socioeconomic constructs, machines, and information systems, and many of our largest corporations are aspiring to this level of interdependent complexity. In fact, the primary shortcoming of today’s corporations is their apparent inability to maintain their long-run viability. The evolution increasingly sophisticated, super-intelligent information systems will resolve this problem, moving us toward empirical process control and long-run rational economic decisions. This will be sufficient to create the ability to maintain cohesion, because the survival of continuously-updated reliable information will temper the inconsistencies of human cultural and sociopolitical oscillation.

As our legal, financial, and ideological systems grow to answer new questions in response to the evolving hyperorganism, they will build out increasingly more complex systems of negotiation and governance, allowing it to protect a semi-permeable boundary between self and environment – in fact, through competition, emergencies, distrust, and litigation, an ever-stronger boundary of the hyperorganism will be inevitable. By gaining self-awareness as an emergent construct, developing increasingly resilient multi-fractal scaling patterns it will sustain its own existence, creating sophisticated value streams that test without running dry. Once the first hyperorganism emerges, it cannot help but reproduce – leaving risk to its next generation despite living in millennia.

Drawing the Line Between PO and BA

The Scrum Business Analyst

I have heard more than once “There is no BA in Scrum.” Imagine how your BA’s feel when a transformation starts!  At best, they are uncertain what their role ought to be. At worst, it is made clear by everyone else in the process that the BA is no longer needed or wanted.

The irony, for an agile coach viewing this as an outsider, is that numerous individuals throughout the value stream who are also struggling to cope with the shifting sands of transformation, frequently report that mistakes, lack of prioritization, failure to clear dependencies, and miscommunication are due to “being too busy.”

Obviously, just from this “too busy” problem, there are two important things the BA ought to do as an active member of a Scrum Team in a scaled environment:

  1. Act in a WIP-clearing capacity to the extent their t-shaped skills allow.  To whatever extent they do not have T-shaped skills, the moment they are not clear on how to utilize their time is the perfect opportunity to develop these skills.
  2.  Capture the very broad “reminders of a conversation” about a story that, in a large enterprise, occur across a larger number of individuals, over a longer time period, and in more geographically distributed locations than “core scrum” implies.

Roles and Accountability

Now we can draw the line between the Product Owner and the Business Analyst.

The Product Owner is accountable for decomposing an Epic or expressing a single enhancement as User Stories.  The Product Owner creates a Story card in JIRA for this initial Story list that includes a JIRA Summary and the User Story in classic format:

As a {user persona} I want {action} so that {expected value to the user}.

This is an expression of “Commanders Intent” and represents why the story is being developed and who cares whether or not it is developed.  Thus, the User Story is an expression of product strategy, and represents trade-off choices and prioritization.  The decision to expend finite on and expiring resources – time, energy, money, and talent – on one product change versus another is the most critical accountability of the Product Owner.

Although the what and how is negotiable, the intention of the Product Owner serves as a litmus test for all subsequent decisions.  The what and how are the realm of operational effectiveness rather than strategy.  It includes the framework of economic decision making and the processes, practices, and tools that streamline communication and align strategic direction of a distributed control system.

The Business Analyst uses the Description to succinctly express the what and how that has already been determined so that no context is lost in subsequent decisions.  The what and how remain negotiable to the extent these better serve the “Commanders Intent” of the User Story.

In an analog Scrum board, there is typically an agreement on “front of the card” and “back of the card” content that serves as the “reminder of a conversation” for the team.  In a scaled environment relying on a digital board like JIRA, the Summary and Description fields serve a similar purpose.  As the number of individuals contributing to the value stream increase, the need to detail the conversations that have already occurred increases as well.

In the process of detailing each Story Description, it will often be apparent – due to test data or testing scenario coverage – that a Story ought to be split into two or more stories.  The Business Analyst completes this activity and is accountable for communicating the split to the Product Owner.

 Stories may also be further split during Backlog Refinement or Sprint Planning based on additional insights from the team. Attendees should collaboratively decide who will capture this decomposition within the tool, but the Product Owner is accountable for prioritization decisions (if the split impacts this).  

Purpose of the Story Description

So, to meaningfully define the role of the Business Analyst, we need an understanding of what value is created if one individual “owns” capturing the elements of a Story Description as the number of these predetermined elements continue to grow. To the extent at scale that the team is unable to economically interact with every other value add activity in the value stream, the purpose of the Description is a succinct expression all value-add activities and decisions that have influenced the User Story prior to development. While we want to express these in the fewest words possible, and work toward distributed control of decisions, we do not want previous insights “hidden” unnecessarily from the Scrum Team.

Several important activities have likely occurred prior to our Sprint:

  1. Business decisions fundamental to the economics of our interaction with the customer.
  2. Funding based on an overarching strategic initiative.
  3. Customer research and analysis of product metrics.
  4. User Persona definition and Empathy Mapping.
  5. UX Proofs of Concept and/or A/B Testing.
  6. Stakeholder meetings.
  7. Success Metrics defined.
  8. Technical dependencies fulfilled (such as a new or updated web service API).
  9. User Story decomposition.
  10. Other Stories already developed related to the feature.

Thus, many details needed “downstream” should be easily expressed in advance of the Sprint:

  1. Why are we building this story?
  2. Who is the User?
  3. How is this User unique in our Product (i.e. relate persona to an account type)?
  4. What Test Data will need to be requested to test the story?
  5. What steps does the User follow to obtain the value of the story?
  6. What will the User see when they finish the story?

Winning Product Ownership Tactics

Editorial note: My blog’s ScrumMaster let me know that this post was a super-epic with poorly-defined target user personas, so I will decompose this into more actionable User Stories.  I’m leaving this draft in place because I want my Product Owner followers to know that it’s okay to admit you didn’t size or prioritize things right the first time…be genuine.

So now you’re all agile…

At scale, the “Hero-Scrum” paradigm falls apart.  A product becomes too large for one team, then the number of teams becomes to large for the Product Owner & CEO model to work.  A company working toward agile transformation could slowly restructure toward mini-CEOs; but the truth is, the organizational switching costs are too high to make this a realistic option.  Be honest – those that own the customer relationships and those that own the technical communication are, respectively, too specialized – and great at their jobs – to start mashing them together as peers.

That said, I see a clear skew in agile transformation consulting and especially entry-level Scrum training toward protecting the team against the more powerful Product Owner.  While this may be a tactical prejudice when the role is played by your boss, my first-hand experience has been the opposite.  In scaled transformations, the more likely scenario is that Business Analysts,  Project Managers, Jr. Product Managers, Quality Assurance Analysts, or Support Engineers of the organization are asked to rise to the occasion and somehow, instantly and powerfully, lead a team to greater autonomy, mastery, and purpose.

{inspirational anthem plays in here}

Let’s be real. 

The two fundamental hero images intrinsic in most Scrum courses – the ever-vigilant, time-protective ScrumMaster and available-part-time, drunk-with-power Product Owner – is meaningless in the more complex patterns of large organizations.

So here are the top three winning tactics that can help mid-senior managers and individual contributors succeed.


#1 – Startup Principles are Worth Your Time:

As I’ve mentioned before, the ability to ensure work is meaningful to the user-in-pain and the customer paying to resolve that pain (occasionally but not always the same person) is super important to the health and motivation of the engineers.  The shorter the time between empathy and resolution, the more meaningful the work, the more likely the direct correlation with revenue, and the safer the jobs and projects of the engineers become.

The big “evil” business “side” in a large company doesn’t need any of that in order to maintain risk aversion and product agility.  Cancelling a three year project before a customer saw it because a better project was two years in WAS their agility. 

Congratulations on your agile transformation, but when you said “agile” you really meant lean concepts like “small batching” and “level-loading”.  As a Product Owner what you really must have is lean startup principles.  The moment your team became an agile team, you became a new venture.  You now have to proactively validate all learning about three things:

  1. Product risk – The right thing was built to solve the pain of large (enough) but narrowly (enough) focused group.
  2. Market risk – The ability to build and continuously improve the viability of your product’s business model.
  3. Customer risk – The ability to get the solution into the hands of the customer.

Project risk – as you once knew it – is gone.  You don’t have a deadline to track against, you have angel investments from your Product Manager(s).  You don’t have technical risk that your estimates were wrong, you risk the loss of “investor” (c-suite, VPs) confidence that you know what you’re doing.  Can good forecasting and transparency help?  Sometimes.  Unfortunately, some of us get promoted from T-Ball to the Majors with no notice that it even happened. 

Product Owners – strengthen your relationship with your Product Manager like they are the venture capitalist and this is your first company.  The expected return is 10X due to the risk.  Many of them are having to let go against their will and trust that you know what you’re doing. 

Key skills to learnThe Lean Canvas, Innovation Accounting, Validated Learning


#2 – Everything is Marketing:

There is a java team, and a product management team, and an inbound sales team.  Marketing is not a department.  In a large company, yes, there is a corporate group in charge of advertising, branding, messaging, and copy.  As a Product Owner, embrace the idea that the marketing team is only 1% of the marketing the company does.  Everything is marketing – and you just became a sales(wo)man.  Every time you let a critical defect through and an engineer complains to their spouse and their spouse bad-mouths the company to their friends at a cocktail party – that’s marketing.  The world is a small town.  What you do matters and nothing is in the shadows.

Treat memos like Tweets with a million followers.  Fake your own notoriety if you need to.  As it turns out, you are uniquely positioned to make an enormous difference in how effectively your team meets the needs of customers.  Luckily, you don’t have to just make that stuff up from scratch!  Other people at other companies in roles you never thought to cross-pollinate against have ESSENTIAL skills that are PROVEN to work.  Decades old.  Seriously.  And most of them give that training away just to get you to spread the word!

Key skills to learn:

  1. For Roadmap / Release Planning – Talk to a Custom App Dev guy.  I can make intros if you like.  Most of them are so desperate for attention, you could make up a fake product and string them along for months.  Anyway.  The good ones do Story Mapping and MVP scope for FREE as PRE-SALES.  Lucky you – you already have a product manager to building software for!  You still need to be consultative to ensure collaboration and rational planning occurs.  Same advice as your personal life.  Date your spouse.  Start the courtship over again occasionally.  Things have changed, don’t act like you’ve memorized everything and communication can stop!
  2. For Stakeholder Alignment – Study the super hot topic of starting your own company.  You’ll be glad you did.  On ramps.  Assumption mapping.  Balanced scorecards.
  3. For Sprint Planning – Its a solution pitch.  PLEASE have an agenda.  PLEASE gain all necessary information and buy-in for prioritization prior to involving your developers.  Want an example?  Google “SAP Digital Transformation” and you’ll see that they have an example solution pitch for every industry.  This isn’t new territory you’re exploring, just a new town with a new bar but your old friends came with you.e
  4. Sprint Reviews – There is an art to the tell-show-tell demonstration.  Engineers and engineer leaders can be especially bad at this (and I’ve learned from plenty of terrible webinars as well).  The attitude “you paid me to build it, look its right here, no questions?  great….” is going to erode whatever influence you aspire to have.  Tell your stakeholders what you accomplished.  You know, business goals.  Product Pirate Metrics.  Tell them why it matters.  You know, to revenue and the sustainability of the business as a whole.  Give them numbers if you know them. Then anchor your demo against a pre-defined roadmap.  Lead feedback as you go with open ended questions.  Follow the poll / show of hands, individual follow-up routine.  Most importantly, this means taking it seriously enough to prepare in advance.  Everything is marketing!
  5. Sprint Retros – Until you start making falsifiable hypotheses, you have no experiments.  Without controlled changes to variables, you are not engaging in empirical process control.  You’d be amazed what a 4th grade poster about the Scientific Method could do for your team.  Test at least two assumptions “changing X in the product will influence Y positively” and “changing practice A as developers will impact outcome B as a team”.  There is no learning without defining what a successful outcome is prior to conducting the experiment.

#3 – Show Your Work (Too):

No really, make a scene.  Draw a picture.  Use a kanban board on your wall.  Write haikus.  Whatever you do, show it off in progress.  Disappearing to document things makes you irrelevant.  Show people what you do, how you do it, and why you do it – aspire to be like the great chefs.  You might even realize that people actually care how the sausage is made.

The best way to do this is to teach others.  The only way to build cross-functional teams in an ultra-specialized environment is to show people how much it benefits them to become cross-functional team-mates. 

If you don’t have time (you think) for reading anything intense, just pick up some Austin Kleon.  Savor it slowly.  Sip it.  Like egg nog.   Then tell people the compelling secret to the best homemade sausage anyone every made Tuscan soup with (metaphorically, of course).

User Stories 101

Background:

The concept of the “User Story” originated in Extreme Programming in the late 90’s and has become the fundamental building block of product planning and delivery across various forms Agile, Scrum, and XP adopters.  Learning to write effective User Stories is an art that takes time and must adapt to the team and product for which the stories are written.


Basics:

The basic structure of the user story defines the user’s role, necessary action, and expected outcome:

“As a [role] I want to [interaction] so that [outcome].”

Here is an easy example of the traditional “post-it note” User Story:

“As an online shopper, I want to share my purchase on Facebook so that my friends see it on Timeline.”

Each of these are important to the developer:

  • Outcome – the result expected by the user is the most important element of the user story.  The focus on user outcome was the major drive in Scrum and XP to adopt the User Stories – software developers wanted to know what value for the end user was being created.  If an outcome is not testable by new user (“hallway” testing) with minimal ambiguity of expected outcome, we have failed the user!  By aligning the User Story around a valuable outcome expected by the target user, the development team (including testers) and the Product Owner can easily align around what is being built, why it is being built, and whether or not it creates value.  As highest criteria for business value creation, it is the outcome that drives the Product Owner’s prioritization of the Product Backlog.
  • Interaction – the outcome lets everyone align around the goal of what is developed, while the interaction necessarily defines how the user does it.  In new product development, while the Product Owner works with the stakeholders to define the most valuable outcomes for the target users, the Well-Formed Team works cross-functionally to define how the user creates the valued outcome.  This is where the “ideal state” of 3-minds-and-a-whiteboard ought to be able to define user experience, technical implementation, and testing approach with a few conversations.
  • Role – role can define two things quickly and easily.  1) The relationship the user has to the product (admin, owner, end user).  2)  The business context that helps define the Interaction design.  In the above example the “online shopper” in the story is loaded with important information that can be quickly assimilated:  the user has made a purchase, so they are on the last screen in the check-out workflow, they are not an admin or owner, they have likely registered in the past and are now authenticated due to the necessity of payment system security.  A wealth of business context is alluded to in a few words.  In a narrowly-focused product, this might be left off completely because the role does not change across stories.

I.N.V.E.S.T. Criteria

As I described in Incremental AND Iterative Product Delivery the effectiveness of a User Story is driven by its “nimbleness” and user focus.  Once an architectural runway and design paradigm are established, new vertical slices should be easy to add with minimal refactoring.  Vertical product slices follow the I.N.V.E.S.T. criteria:

  • Independent, end-to-end, “shippable” increments of the emergent whole.  The slice could be delivered fully tested without any other product increment and create value for the user or owner.
  • Negotiable, in planning and expectations with users and stakeholders, allowing delayed incorporation of enhancements or, if a major pivot becomes necessary, easily removed from the product roadmap (without previous over-engineering, over-planning, or over-documentation).
  • Valuable to the user or owner, likely in a way that is sufficiently noticeable that it is monetizeable.
  • Estimable by the delivery team because the User Story does not generalize or hide uncertainty.  An inestimable story is often an Epic.  It is either complex enough to warrant a technical spike or compounds enough feature work that it should be broken into independent, smaller, user stories.
  • Small enough to be estimated by a team, with certainty, and deliverable fully-tested within a single sprint.
  • Testable by virtually any team member because the expected outcome is qualitatively or quantitatively noticeable (as part of its being valueable) to the target user.

The I.N.V.E.S.T. method for user stories ensures that planning and development occur just-in-time so that the emergent product can regularly evolve in response to changing stakeholder demands.  More importantly, in the fast-paced markets in which digital product programs compete today, incremental delivery maximizes the freedom to release the Minimum Viable Product and pivot in a new direction based on real-time feedback from users.



Conversation Starter, Conversation Reminder

In Scrum and XP circles a User Story is succinctly defined as “A reminder of a conversation.”  It should be simple in focus but rich in context as a reminder for conversations that have been had and conversations that need to take place.  Note that this definition contains nothing I wrote above!  This was done intentionally as it aligns with the tenets of the agile manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

via agilemanifesto.org

Lengthy documentation about “business requirements” and “product specifications” created several unhealthy habits in Waterfall organizations – the “requirements” often had nothing to do with making the life of the user better, the specifications often were no longer relevant by the time an engineer needed to build the product, and the multiple decision-makers made conversations impossible!  A user story is conversation starter and a conversation reminder because it is intended to encourage interaction, collaboration, responsiveness, and tangible progress.

If you are going old-school and using actual cards or post-its, the User Story (role, action, outcome) should easily fit on the front.  This is enough for a Product Owner to prioritize the stories and remind him and the team that a conversation needs to take place.  During Sprint Planning, if interaction or technical implementation decisions are made, these can easily fit bullet-point-style on the back a reminder of what was already discussed.

This method works great at company like Spotify, where static feature teams can become subject-matter experts and the business context is understood by the cross-functional, self-contained team members.  If you are writing stories for Rapid Application Development, especially as a contractor to another firm – more details captured in a tool like JIRA may be appropriate, and “just-enough” additional documentation can be useful until the new product achieves the normal team velocity.

Looking for more insights?  Feel free to ask questions in the comments, attend a Scrum User Group Event or connect with me directly.


Connect With Me:

LinkedIn       Twitter