Chapter n - Planning via Agile Story Maps

"If you have a problem with Agile teams missing commitments

and you think the root cause is in the Agile Methodology , 

maybe you should look at the organization's management style

 and ask why there is a lack of accountability.

There is no reason commitment to deliverables

has to be mutually exclusive with Agile."

Planning Integrations via Agile and User Story Maps

If we focus ourselves on planning any individual workstream on any particular deal, we can follow the standard model of pulling out a Gantt chart playbook with hundreds or thousands of line items each with specific start and end dates and begin customizing it. This is the approach that I find the vast majority of IMOs take and yields something like this:

Or in Excel/SmartSheets

Does this look familiar to you?  Do you look at this and say "Yes, that is a good plan!" that I am proud to go show the Senior Executives? Does it tell a good story?  Maybe it is; I have, unfortunately, worked with some senior executive who truly believed that if we only had a good Gantt chart we could solve both climate change and peace in the mid-east. 

Alternatively, I am proposing an Agile Story Map approach to workstream planning.

As a starting example, let's consider the selling process workstream which I'll refer to as "Lead-to-Fulfillment Workstream."  This value stream includes the preparation of the post-close organization to sell the acquired product. The workstream then moves to product marketing and lead generation, initial sales calls and sales engineering, proof-of-concept and trial deals, pipeline management, the actual sales transaction, proper accounting for the transaction and finally delivery to the customer.

The goal of Story Mapping is to look at the plan in two dimensions: time along the y-axis and workstream sub-area in x-axis. This way, we at any point in time, we get a complete end-to-end view of what capabilities are being delivered.

For discussion, let's put Demand Generation, Lead Generation, Opportunity Management, Configuration/Pricing/Quoting, Booking & Delivery and Customer Support as significant workstream elements.

We then look at what capabilities in each element will be delivered over time. The important thing here is that each element needs to think both within its own scope as well as within the entire scope of the workstream.  For day-1, we can look horizontally across all of the epics to get an in-context vision of how all of selling will work on day-1.  We can then look down through the phases to visualize how our selling process will mature and integrate through the duration of the integration, all in context of the entire workstream.

For each epic (the black boxes), the stories are developed representing the operational state of the organization through the progress of the integration. The Stories are built out with enough design detail so that any reader can visually see a summary of the state and then drill into the stories to see much more detail. This becomes both a design document as well as a schedule. But the schedule is following an Agile approach. The phases of the project I like to use are:

o   Getting to Sign

o   Announcement

o   Getting to Close

o   Day-1

o   Week-1

o   Month-1

o   Quarter-1

o   Quarter-2

o   Quarter-n

At first pass, let's just plan our work at this phase level and while this level is good for a preliminary plan, it is not good enough for the integration execution level. As each phase draws near, we need to take the level one further level of detail. For phases approaching on the near term horizon, we break the work down into Sprints that can be about one or two weeks long. This level of detail allows us to document dependencies and is more akin to a detailed plan.  Development teams are familiar with the Agile Release Trains and Planning Increments which are fleshed out and planned from backlog into sprints.  This same process holds here.  

At this point, I'd like to address the quote at the top of the chapter...  one common complaint I hear about Agile is that schedules don't matter and deliverables keep slipping to the right at the whim of the developers.  My response to that complaint is that this phenomena is a result of weak leadership rather than a flaw in the process.  Leadership must build an environment where important deliverables are identified and teams are held to account for making the deliverable happen.  If everything is slipping to the right and alarm bells aren't going off then something has to change in the governance of the project.

For project managing the current phase and sprints, we can then use traditional Kanban boards to track the progress of each sprint and use dashboards such as burn-down graphs to manage the program.

There are some special case epics that I would also like to suggest...

We all know there are some workstreams that apply to everyone. Some examples are: every workstream needs to evaluate their vendors, every workstream needs to look at their applicable policies & procedures, every workstream needs to evaluate their enterprise applications and so forth.

The challenge is where do we plan these and where can we see these? On one hand, IT wants to see all of their enterprise application efforts in one place. On the other hand, it really only has context if we look at the application design in the context of the workstream. With modern database based tools, we don't have to choose, we can see it in both places. Within each workstream, I have created special epics for each of these special cases and then use tagging to indicate the nature of the special case.

I create an epic for "Enterprise Applications" in every workstream. In this epic, we plan out the evaluation and migration of any tools. Since they are then tagged appropriately, we can then go to an IT Story Map and aggregate all enterprise application stories.

I create an epic for "Policy Alignment" in every workstream. In this epic, we plan out the evaluation and unification of any policies. Since they are then tagged appropriately, we can then go to an Policy Story Map and aggregate all policies across all workstreams.

Similarly, “Vendors” are assessed within the context of each workstream.

Tools for User Story Maps

I’ve been trialing several tools to help implement Agile Integration and am settling in on some that I am happy with.  The core of my planning is now done in Jira which provides the basics of workstream organization, epics within each workstream and the breaking down of epics into stories.  The latest trial instances I am using has just a few low-level stories rather than real playbook data, but it gives you an idea. 

To provide the User Story Mapping visualization of the high-level plan I am evaluating two solutions.  The screen-shots may be hard to see so you may need to zoom your screen to see them.

• StoriesOnBoard has traditionally lacked the reliable synchronization of its maps to Jira details but recent updates seem to have made the sync much better.  With StoriesOnBoard, we get very nice User Story Maps such as this one sketched out for Lead-to-Fulfillment.  In SoB the ability to use the yellow second level organization cards is a differentiating feature.

Becomes the following in the tool.

•  Alternatively, we can use the EasyAgile User Story Maps plug-in for Jira.  This is nice because it is native to Jira and does not rely on any ‘sync’ of data.  The downside to this compared to StoriesOnBoard is that we only have two levels of organization rather than three.

For each of these methods of planning out the high-level strategy, we can then take these stories laid out in phases and begin the next level of planning.  For near-term phases, we would do a Planning Session where the stories are scheduled into sprints. Dependencies are verified and execution begins.  The tools for this are the “Backlog” scheduling screen and the “Active Sprints Kanban”.