By Brian Lucas

This one is dedicated to the lovely Jennifer, my dear and loyal friend, who found inspiration, dared to be creative and discovered a new world of possibilities.  Your future has a bright star!

“When we try to pick out anything by itself, we find it hitched to everything else in the Universe.” – John Muir

Often in new concepts or even old ones, people are overwhelmed by terminology or individual ideas.  They get so hung up on process and bogged down in details; they cannot see the forest through the trees.  Agile is no exception.  The missing part of the agile equation is a view that shows the relationships between some of the most prominent common elements in agile.  Adopt this view, and you will find many of the elements that cause people to stumble in adopting agile, transition smoothly into one another.  Everything after all is interrelated and necessary in an agile system or it does not belong.

I received so many questions about story mapping, epics, kanbans and user stories in the last month, I decided to show you how I tie them all together.  First let’s lay a little groundwork.  User stories are one of agile’s greatest advantages.  They can also be a serious stumbling block for those who struggle with the concept.  Having a product owner start out creating a backlog of user stories is difficult for the uninitiated.  The language is often weak, ambiguous and even downright misleading.

Gherkin[1] is a popular language format that uses Treetop grammar that can take advantage of proofer software tools like Cucumber to validate the user stories.  Even if you are following the Gherkin language constraints, you can still create awful user stories.  Let me offer a point of clarification here.  While I find benefit in Cucumber proofed Gherkin statements using Ruby[2], it is not something that should be followed religiously or become more of a procedure than an expediting tool.  You will hear this theme, time and again from me; if you are rigidly adhering to a process or even a tool you are not being agile.

Gherkin’s real benefit is that it helps users, developers and testers come to a common language, I like to call “agile speak.”  You will see it often in development teams and users that have been together for years.  They use common forms of expression, a standardized set of subjects, verbs and objects.  Interestingly, they also practice an economy of language.  Rather than writing and speaking verbosely, they focus in on the critical aspects with considerable concision.  If you look at most teams that are sporting high velocity, you will find them practicing this type of communication.  In saying this, I am by no means denigrating the benefits of Gherkin in automated testing, which I highly encourage[3].

All this grew out of Dan North’s work on Behavior Driven Development (BDD)[4], which in turn, was created to address some of the deficiencies of Test Driven Development (TDD)[5].  I will admit to mixing the two terms because I think it is a very silly practice to follow a concept and become obstructed by its limitations.   My natural inclination is to adapt it to fit the needs of the situation and not follow a silly checklist[6].

BDD[7] is a combination of TDD and domain-driven design (DDD)[8] and object-oriented analysis and design (OOAD)[9].  Eric Evans, the father of DDD, states:

“By using the model-based language pervasively and not being satisfied until it flows, we approach a model that is complete and comprehensible, made up of simple elements that combine to express complex ideas…  Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding; developers should watch for ambiguity or inconsistency that will trip up design.”

The introduction of this ubiquitous language concept was a start on agile speak, but far too formalized[10] to be effective in an agile sense.  Still, it was a step in the right direction and laid a groundwork for non-procedural thinkers to adapt it to make it usable   The point here is, communication and the smooth transition of knowledge from initial conversation and concept of product owner to implemented code is critical to being agile.  I know that seems like an obvious statement, but so many keep missing this vital point.

So how do epics, story mapping, kanbans, user stories, test criteria and code fit together?  The answer is the former becomes the latter or at least has to easily flow into it.  Let’s start with epics.  If you read my blog article, When to use epic user stories, you will see the following parable:

One day a traveler, walking along a lane, came across 3 stone-cutters working in a quarry. Interested to find out what they were working on, he asked the first stone-cutter what he was doing. “I am cutting a stone!” Still no wiser the traveler turned to the second stone-cutter  “I am cutting this block of stone to make sure that its square and its dimensions are uniform, so that it will fit exactly in its place in a wall.” The traveler turned to the third stone-cutter  He seemed to be the happiest of the three and when asked what he was doing replied: I am building a cathedral.” – The Stone-Cutters Parable by Unknown

The Stone-Cutters Parable is one of my all-time favorites for simplicity, ease of understanding and wisdom of its message.  A good way to begin any agile software development is through an epic that describes the software solution you are creating in terms of the cathedral, in other words, the big picture.  This represents the product level epic story in my agile philosophy.  It is a very similar concept to a level zero data-flow diagram or a narrative description of a conceptual system model.

Out of this product epic flows the epics that make up the major parts of the system.  Here is where the epics begin to become a story map.  Shuffling them around on a whiteboard with post-its or using an electronic tool or merely sequencing them in a repository like Team Foundation Server (TFS) is up to you.  I favor electronic means because they are efficient and provide a permanent record you can build on.  The story mapping[11] activity with all due respect to Jeff Patton[12], is an old concept similar to functional decomposition or work breakdown thinking to begin to organize and atomize the epics into a chronological system flow and sets of user stories.

This provides one of the broadest understandings of the system.  It is by far and away one of the most useful tools for communications.  It is here that one of the great communication links to social media can be established.  Both by bringing in customer input and promoting concepts to your current and potential customers.  This is why I like to see another element added to the user story/epic elements.  I call is social media characterizations.

These have two categories: unrefined feedback and promotional features.  Unrefined feedback is responses and comments you get from whatever social media you use that have some bearing on the epic or user story.  These should be associated via links or included notes to the epic or story if you are using TFS.  I prefer links because they take you into the world of the social media where the feedback came from and has an added flavor of context.  Promotional features are key phrases, language and copy that will be used by the marketing and sales teams to promote this particular element of the system whether internally of externally.  It doesn’t have to be perfect copy, but it should be close[13].  I don’t want to go too far into this concept here, since it merits an article of its own.

As the story map builds out; a wonderful thing occurs.  As it reaches its full potential at a high level; it becomes an excellent tool for managing distributed agile efforts.  Each high level epic becomes a division of labor for a different development team’s planning sessions.  The master epic is the basis for the scrum of scrums sessions, if you are following scrum.  Each team can see exactly how they fit into the big picture and what their efforts will affect.  It is rather like the information one gets from Gantt[14] or PERT[15] charts, but is more relevant, since it is sourced in the solution itself.

From an operational perspective, you will see something wonderful emerging.  A Kanban[16] naturally appears before your eyes when atomic user stories are finally decomposed and the product owner layers in priority.  If you were working in a tool like TFS all along; you are ready to start cranking on your first sprint of your first release.  Better still than there being no time lost; there is no information or knowledge lost.  You have taken everything from the initial concepts right down to what is going to drive program code and interrelated it.

Remember you are not writing a definitive specification up front!  That is not the agile way.  You are only creating enough of a skeleton to get you down to the necessary specifics to get the development team actually able to write code.  The top layers will almost always change at least a bit as you gain more knowledge as sprints and releases pile up.  That is why you don’t want to spend a lot of time in upfront analysis and requirements gathering.  One, you will never think of everything and get it all right.  Two, by the time you are done, it will no longer be relevant.

So let’s recap, if you follow these suggestions, you have a mechanism to describe all of the following all in one repository:

1. The system in a nutshell via the product level epic.
2. The language the marketing and sales people will and should use via social media characterizations.
3. The means to safely allocate work in a distributed agile effort via the high level epics in the story map.
4. The communication vehicle that shows the interrelationship of all the system elements at various levels of detail via the breakdown of epics.
5. The best possible kanban for controlling production activities via the organized and prioritized atomic user stories that decomposed from their epics in the story mapping effort.
6. A great vehicle to show the impact of knowledge gained during the development and how it affects the system via updated epics and story maps.

Of course, there are a lot of details here that I cannot go into in a simple blog article.  But I have found from experience; if you put people on the right path, they will work out the details of the journey themselves.  That is, if they are agile.  So remember till next time, keep agile!