Using Hoshin for Agile User Story Management

Standard

I am a big fan of Hoshin Kanri for taking a strategy from vague aspiration to actionable tasks. Three years ago I wrote a blog on creating a strategic plan. The final step I describe in there is taking the findings of the PESTEL and SWOT analysis and converting them into actionable tasks for the 12 month calendar. While I did not mention it in the article, this process is easily managed through Hoshin tools and techniques. It strikes me that similar techniques could also be used to take Themes to User Stories through to Tasks in Agile development.

What is Hoshin Kanri?

I learned about Hoshin from Cowley and Domb’s “Beyond Strategic Vision” as part of an MBA course I did a number of years ago. This book has lots of tools you can use to break down a high level strategy into objectives, to goals, then to tasks.

hoshin_kanri_explained2

Thank you to www.hoshinkanripro.com for the excellent image.

In short, the boss at the top sets the ultimate mission and then pass down to the next level of management for them to determine the objectives, then down to the next level to set the goals and then down to the “coal face” to determine the actual tasks. The big advantage of the approach is the goals of the business are met, everyone is informed and every level gets input into what they will be doing.

The “Beyond Strategic Vision” book has a great diagram showing Hoshin in action.

WP_20160126_21_15_03_Pro[1]

The great insight of the process is that the difference between a mission and a task is the effort involved. Whether something is a strategy, tactic, or task is a case of how much it has been broken down and how easy it is to achieve.

The tools of Hoshin are focussed on developing consensus on what is being achieved and a clear definition of success. While going through the tools is literally a book in itself, this reminds me of the struggles in Agile of going from Theme to Task.

The Struggle of the User Story

Agile development has a hierarchy in its “Stories”:

  • Theme: Describes the overall product e.g. a self-service web portal for CRM
  • Epic: Describes key requirements which may need further breaking down e.g. the web portal should be HTML5 compliant
  • User Story: A plain language description of a feature, often in the form of “As a <user type> I want to <action> so that <result> e.g. As a customer I want to use the web site on Microsoft Edge so that I can manage my CRM record
  • Tasks: Small actions which build the User Story e.g. code the style sheets in compliance with html5 development standards

In this case, the goal is to create Tasks which can be done in a day or two. A problem often encountered is how to break the Theme down into such small components, especially in larger projects. The truth is, just as with the Hoshin process, the difference between an Epic, User Story and Task is a matter of effort involved. The key is making sure the Tasks contribute to the User Stories above them and so on up to the Theme. To put it in Agile terminology, we must ensure the Tasks are sufficient to meet the User Story’s Definition of Done and so on up the chain to maximise value to the client.

An Example of Hoshin for Agile

One tool used for root cause analysis in Hoshin is the Ishikawa, or Fishbone Diagram. This is used during brainstorming to take a big problem and identify the underlying causes. These are then analysed to determine the major contributors and which will be tackled as part of that round of activity. I am purposely framing this in a way to sound familiar to the User Story process of identifying high impact activities to provide immediate value to the client, while leaving less impactful activities on the backlog for another sprint. Another page from the book, shows the Fishbone Diagram at work (it is read from right to left in this case).

WP_20160126_23_00_12_Pro[1]

Using a Fishbone Diagram could be used to help identify the User Stories in Agile planning and identify those of high value. Similarly, it could be used to brainstorm the Tasks required to achieve a specific User Story and, as we add the bones, determine the effort to see if we have gone far enough.

Bringing Automation to the Process

Taking this to the next level, if we can formalise the process for generating User Stories and Tasks, we can automate the creation of the product. Fellow CRM blogger, CRM CAT (http://crm.fueledbysleep.com/) has just finished a thesis talking about taking a Use Case and creating prototype code from it. The thesis is not yet online, but the documentation behind her code is, as is her prototype program. In the future I see a User Story being broken down into Tasks and the structure being fed into a program like CRM CAT’s to get a lot of the simple development and configuration out of the way. Exciting times.

Conclusions

If you struggle with taking an Epic down to User Stories and then down to a complete set of Tasks, consider looking at the tools of Hoshin to see how they could help. At worst, it will give you a great strategy-planning tool to add to your toolbox.

Also, check out CRM CAT’s prototype. The idea of taking plain English and converting it directly into code is, to me, very exciting and to see how the program takes something akin to a User Story and turn it into code is, frankly, amazing but something I imagine we will see more and more of in the future.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s