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 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, 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.
All this grew out of Dan North’s work on Behavior Driven Development (BDD), which in turn, was created to address some of the deficiencies of Test Driven Development (TDD). 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.
BDD is a combination of TDD and domain-driven design (DDD) and object-oriented analysis and design (OOAD). 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 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 activity with all due respect to Jeff Patton, 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. 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 or PERT 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 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:
- The system in a nutshell via the product level epic.
- The language the marketing and sales people will and should use via social media characterizations.
- The means to safely allocate work in a distributed agile effort via the high level epics in the story map.
- The communication vehicle that shows the interrelationship of all the system elements at various levels of detail via the breakdown of epics.
- 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.
- 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!
 But do not under any circumstances make it a procedural rule. The test team is in the best position to determine what should be automated and what should not and when it should be done. This should never be dictated by a project manager who should not be working on an agile project in the first place or senior IT management.
 See Beck, K. Test-Driven Development by Example, Addison Wesley – Vaseem, 2003
 Unless the checklist makes sense.
 Dan North created the first BDD framework, Known as JBehave. He followed this with a story-level BDD framework for Ruby called RBehave. Chris Matts, in 2008, came up with the idea of Feature Injection, pushing BDD into the analysis space making BBD a full software lifecycle development method.
 See Evans, Eric (2004), Domain-Driven Design — Tackling Complexity in the Heart of Software, Addison-Wesley.
 See Grady Booch. “Object-oriented Analysis and Design with Applications, 3rd edition” Addison-Wesley 2007
 I am not going to go into Entities, Value Objects, Aggregates, Aggregate roots, Services, Repositories and Factories. Suffice it to say that while I support and do use taxonomies not everyone is a scientist and any method that is going to be effective needs to be effectively operable under graduating levels of sophistication.
 Anyone who has been in technical development has experienced at least once in their career a situation where marketing and sales are misrepresenting what the product was intended for and actually does. This is an excellent way to prevent that from happening and building up a team mentality.
 See H.L. Gantt, Work, Wages and Profit, published by The Engineering Magazine, New York, 1910; republished as Work, Wages and Profits, Easton, Pennsylvania, Hive Publishing Company, 1974.
 See Fazar, W., “Program Evaluation and Review Technique”, The American Statistician, Vol. 13, No. 2, April 1959.
Another GREAT post Brian! I was waiting for you to write an article on this, since it was part of the advice you gave us and it is working out very well. Many of the outlying members of our organization that were not understanding agile and even some of of our senior product managers that were resisting our efforts have now come on board. They all say the same thing, :Now we see it!” We were even able to reduce the upfront orientation time we build into the start of a release. A nice added bonus that I would like to add to your list of benefits is that the team velocity will increase and the software defects will go down. Both are because the development team has a better understanding of what they are doing. I too, appreciate the Stone-Cutter’s parable. Thanks again for all your advice and help! Your friend – Jack.
Thanks for sharing with us all Jack that this worked for you. I’ll admit it sounds great. Since you actually implemented it successfully, I’d like to ask the question(s) how long did it take you and was it hard? I’d like to do the same thing in my shop.
This is quite good! Though I could have passed on the history of BDD and the others, I understand why you covered them. I have never seen this level of agile explained this way before and I admit it adds to the clarity and is an enormous stride in making it a contiguous expression of need and fulfillment. I especially like your concept called social media characterizations and where and how you are connecting it in your “philosophy” as you call it. It seems you don’t like the word methodology, but that is what you are defining here to my understanding. Would you be open for a few questions by email?
John Kisch, CSM, PMP
Super post Brian! You present the case here very well and it makes tremendous sense to me. I wonder if this tactic could be adopted for reorganization efforts? What do you think?
Very fine portrayal of how an agile project should look and work and too seldom does. What I like most about your approach Brian is that it is simple to understand and appears to be simple to implement. I would appreciate it if you posted more on this subject. Also are you open for a few questions?
Simple, Elegant and Efficient! Brilliant!
Amazing concept! It seems so evident now that you have explained it. Do you have any actual examples that you could send me? This was a great share.
If you are going to send out examples can you include me?
I hate to say me too, but if you are going to email samples I would love to be on the list! This was the best explanation of how to fit this level of scrum together that I have ever seen. Thanks man!!!
Thanks so very much for posting this Brian! Your mastery of agile never ceases to amaze me. This helped out so much with our front end issues. You are a lifesaver! I am looking like a hero in my new lead scrum master role thanks to you. And thank you for answering my emails with such detailed and quality answers. So few bloggers do! You definitely deserve the title of MASTER AGILIST!!!!
This was a real eye-opener for me! This concept makes everything fall into place. I cannot believe that I did not see this before. It is simple and elegant as others have said. It solves many of the problems that we have been struggling with. I seriously appreciate how freely you share your expertise Brian. I have two questions for you if you are willing. One is can you go through your tips on user story development and two is can I get a copy of your examples of this process as well? Thanks for another terrific post!!!
Slick way of sewing it altogether! Thanks Brian, these are great tips.
This is a very useful explanation of how agile flows together in the beginning of the release and/or sprints. I have never seen it explained quite as succinctly or clearly as you have expressed it here. That is as the saying goes the sign of a true master! I was hoping that you could elaborate a bit on you philosophy of refinement. Particularly in regards to user stories. Thank you for writing such an informative and great blog! :Kassim
Brian have you written any books on Agile? I looked, but couldn’t find any. I would like to check them out since you seem to be such an expert and know so much about both the theoretical and practical side of things. Hey for that matter have you written any books about anything else? I think you are a fascinating writer and would like to try out just about anything you have written. So much on the web is garbage or boring you are neither.
Hey count me in on that Brian! If I buy one of your books will you autograph it for me?
Brian Lucas brings clarity out of confusion. Excellent post!
Brian, Keeping Agile is a great blog. It is informative and entertaining. I do have a question on this post. Do you find it necessary to have a very tight integration between the higher expressions of the epics and the user stories or is the user story itself the most important item. What I mean by that is can you create a user story that expands the scope of the epic without having to go back and update the epic or not. It seems to me that if you always have to go back and update the previous level its more documentation maintenance and that’s less agile. Can you clarify for me?