Showing posts with label User Story. Show all posts
Showing posts with label User Story. Show all posts

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?

Wednesday, October 17, 2012

Checklist: the Story is Ready for Development

Here is a simple check list for verifying a Story is ready for development. 



  • I have considered the high level design change for this story
  • I know the code area which need to be modified / created for this story
  • I have thought and considered the flow changes introduced by this story
  • I have looked at the existing test automation for the current flow/behavior (as is)
  • I have thought and described how I will validate the flow/behavior changes introduced by this story (to be)
  • I understood all the current acceptance criteria (ACs) for this Story
  • I am happy with the current ACs for this Story  (I don’t see the need to create a new or remove any of the ACs for thÌs story)
  • I thought about it, and I believe this story should not be split into smaller pieces
  • I thought about it, and I believe this story should not be merged with another one
A missing checked item will trigger a Story huddle, and the story will not be considered ready for development.

Tuesday, May 1, 2012

Inception activity for discovering User Stories

On this blog post I share an activity I used on my last Inception.  I found this activity very useful to kick start the User Stories creation.


What are the goals of this project?
This question  triggered the conversation about the business goals for the project. 

Who will use this system? What are their roles?
These questions disclosed the personas (with their roles) for the project. Goals and personas were written on post-its. Large pink post-it was used for goals, and small colorful post-its were used for personas. This is shown on the photo below.


After having written a few goals and personas, the team started brainstorming for creating User Stories.

As a X, I want Y so that Z.
Note that X and Z were already known variables (personas and goals). We were now looking for the Ys.

So, what does X want from the system in order to achieve Z?
For example: What does an OPS dude want from the system in order to monitor the browser against system overflow?

User stories were being written...

Soon these stories were combined into features (blue post it). Usually a feature would have from two to eight stories.

This whole process was not linear and definitive. Index cards (for stories) and colorful post-it (goals, personas and features) were written and re-written a few times. Below are a few photos showing index cards and post-its.


Friday, February 3, 2012

Back to the basics: What made this Agile Inception especial?

The following two pictures depict the latest Inception I participated at.








A little bit of history: For the past two years I have participated directly in 3 Inceptions, and indirectly in 5 inceptions. By directly, I mean, I was sitting in the war room for most of the Inception sessions. And by indirectly, I mean, I was participating on the Inception sessions over video from a Nearshore location (onshore is San Francisoc, USA, nearshore is Porto Alegre, Brazil).

I attribute the success of the last Agile Inception to 3 things: collocation, war room, and colorful post-it.

Collocation

Don’t under estimate the value of a face to face interaction. I am currently in Brazil and I am used to having effective meetings over video and phone with USA. I know that technology can bring people closer together, and, perhaps, we can work together without sitting next to each other. However, the face to face during Inception will bring the team together in a way that it will be worth each penny spend for making the collocated Inception a reality.

I compare it to dating and internet dating. Relationship development goes to another level when the whole team is at the same room. Think creatively on how to save on costs. In our case we were able to reduce the collocated period by having a pre-Inception period before the collocate Inception. Spikes, research, data gathering, codebase analysis were the sort of activities we did in the pre-Inception week.

War room

Keep a single room for the team during the intense Inception period: the war room! The room should fit all team comfortably. It must have a clean table and wall space. The room should also have a cabinet or a box with index cards, colorful post-its and pen.

The war room makes the environment for collaborative sessions. It also avoids the waste of time of people moving from one room to another. Another important point is about carrying the information between rooms. You can either carry all hand-written notes (index cards, post-its, flip-charts, etc) and put them back in the wall and tables, or upload them on a digital format and carry it on your laptop. The former option is a waste of time. The later lessens people interaction. There is no replacement for writing on and tearing apart colorful post-it or index cards. Once the information goes to the computer, it will not get back to paper. People interaction reduces as there is nothing on the table to gather around.

colorful post-its

Do not bring a list of existing user stories to the Inception. I am sure there is a list somewhere (excel, Jira, or alike). Use it for reference, but don’t use it for driving the Inception sessions. Print a few copies and bring them to the war room. Let people consume it if required. Try not to read items from a list during a collaborative session. In fact, do not build a list while in a collaborative session.

Group people around colorful post-its. Write and place post-its either on the table or at the wall.. Talk about them. Write a few more. Tear them apart. Make use of colors. Reorganize it. The collaboration from using such basic, low-fi technology— colorful post-its and pen—cannot be matched by any digital alternative (file sharing, projector, spreadsheets, etc).

The picture below depicts a great example from my last Inception. Without a previous encoding, the team decided to use the colored small post-its for personas. User Stories (in green post-its) were placed on white index cards containing numbers and estimated (with notes on the back).


On future posts: user story mapping for driving Inception, and a few notes on Inception facilitation

Tuesday, November 23, 2010

Splitting CRUD stories

Two of my colleagues came across a CRUD (Create / Read / Update / Delete) story, and asked me for advice on how to convince people on splitting stories.

I typically prefer to have smaller stories. In this case, instead of having one CRUD story, I would have one for Read, another for Create/Update and a story for Delete.

Here is an example.

As a online store owner, I want to Create / Read / Update / Delete products so that I can offer my customers the top rated products

Instead of having this CRUD story, I split it like this (I will add a few sample tasks for making it more illustrative):

As a online store owner, I want to Read (view) my products so that I can review what is current available on my site

Sample tasks:

  • Create DB table
  • Populate table with a few sample data
  • Create select DB script
  • Create for viewing my products
  • Create automated functional tests for viewing functionality

As a online store owner, I want to Create / Update a product so that I can offer my customers the top rated products

Sample tasks:

  • Create insert / update DB script
  • Create UI for create / update a product
  • Create automated functional tests for adding product functionality
  • Create automated functional tests for updating product functionality

As a online store owner, I want to Delete a product so that I can offer my customers the top rated products

Sample tasks:

Create DB table for deleted products

  • Create delete DB operation
  • Create UI for deleting a product
  • Create automated functional tests for the delete functionality

This sample is very specific for CRUD stories. There are other ways for splitting stories.

Mike Cohn's book, User Stories Applied is a must read on this subject.

Splitting (or deciding the size of a story) is controversial. Mike Cohn have popularized the INVEST acronym: Independent. Negotiable. Valuable. Estimatable. Sized appropriately. Testable

agree with the S in the acronym listed above: Sized appropriately.

But when I first read the INVEST acronym, the S was for small. I know Sized appropriately is not very specific, but it is more realistic. It is not about being small; it is about being sized appropriately. For this consider several reasoning on splitting your stories. The links below have more on this subject:

http://lassekoskela.com/thoughts/7/ways-to-split-user-stories/

http://agilecoach.typepad.com/agile-coaching/2010/09/ideas-for-slicing-user-stories.html

http://xp123.com/xplor/xp0512/index.shtml