Monday, September 2, 2013

User Stories and Business Hypothesis



As I find myself diving deeper into the Lean Start up and the Lean Analytics world, I start questioning some of the Agile practices that been  have followed me on every single Agile project I worked on. For instance: the User Story.


As a < type of user >,

I want < some goal >

so that < some reason >.


This User Story format was created by Mike Cohn years ago [Users Stories Applied], and ever since it has used by many Agile teams. Typically, a Product Backlog has a list of User Stories to be worked on.

Nevertheless there is another kind of work which Lean enthusiastic are bringing to everyone’s attention:  hypothesis.


Hypothesis is a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation.


I have learned the following representation from Alison Vale and Rodrigode Toledo.




Basically I was seeking a better template for a hypothesis. The User Story format was not working for this one. I need a good format to describe the ?, the -> and the ! – my hypothesis, the work needed in order to get this hypothesis in play, and the way to validate the results.


So here is my recommendation for a simple and generic hypothesis format:


If < I do this > then < this will happen >


I am currently calling these Business Hypothesis (please share if you have a better name for it). It includes the ?, the -> and the !; being the ? and the ! explicitly on the text, and  the -> should be handled as details for that hypothesis. This is similarly to User Stories, where the implementation details are not contemplated on the format as a… I want to… so that…

This has been working well for the teams I worked with. Please share your experience with hypothesis. Has this or other formats worked well for you?

6 comments:

Alexandre Klaser said...

Some people call it Hypothesis-Driven Development. There are some good presentations about it (from Jeff Gothelf, Jez Humble).

Maybe some differences on what you propose is that the hypothesis being created may comprise several user stories and the format used, where the goal and how to measure it are really explicit:

"We believe that
[building this feature]
[for these people]
will achieve [this outcome].
We will know we are successful when we see
[the signal from the market]."

Paulo Caroli said...

thanks for the reply.
I like your format as well.
it is definitely more explicitly.

Andy Palmer said...

Mike Cohn used the Connextra story format as presented at XP Day 2001.

http://agilecoach.typepad.com/photos/connextra_user_story_2001/connextrastorycard.html

I use different story formats for different reasons, but one I particularly like I heard from Phil Parker

As a CFO
I can't see the company accounts
Therefore, I need a ledger

It's very useful to phrase stories in terms of things that you can't yet do, and fits nicely with Dan North's BDD philosophy (What is the next most important thing that the system doesn't yet do)

Mike DeCleene said...

Nice post, Paulo.

I also think some of the dissatisfaction is that people have gotten in the habit of writing user stories to the functionality as opposed to the goal

As X, I want a way to accomplish goal Y, so that I get benefit Z

is considerably better than

As X, I want a button that does Y, so that I can do vaguely useful sounding Z.

I also like thinking about the Feature Injection idea of starting from the goal and "hunting the valuable things" related to it, along with the "In order to accomplish A, B needs a way to C"

That said, stories are really more "here's a thing we want to build" over "here's an experiment we want to do." So all for better ways to record "we want to do an experiment."

Paulo Caroli said...

Thanks Mike and Andy.
I really appreciate the valuable contribution.


Karan Bisht said...
This comment has been removed by a blog administrator.