A Promise to have a Conversation

I’ve been writing user stories for a couple of years now, and the best way I’ve heard how to describe them is that they are a promise to have a conversation.  Enough information should be written down to give the reader an idea of what the gist of the story is (and to be able to roughly estimate a story point size to it), but the details are to be driven out during discussions between the product owner and the development team at the start of the sprint.

And that concept works well when the product owner and the development team are located in the same location.  As a product owner, I could attend the daily scrum meetings; I was available to the developers/testers/technical writers to answer questions as they arose.

Recently, however, I’m working on a project where the development team is not located with the product owners.  In fact, development may be done in several different locations around the world.  This introduces several layers of complexity that a co-located team does not have.  Not only is there distance differences between the various team members, but now we also introduce time zone, language and cultural differences as well.  As a result, there is a greater documentation requirement than I have had to deal with before.  While the promise to have a conversation still holds, the product owner is just not as available with a geographically diverse team.

Story Size – Large vs. Small

So one of the first hurdles to jump was what the appropriate size of the user story is.  I’ve had some interesting conversations with various people about this topic, and opinions do vary.  Some feel that user stories should tell an end-to-end story.  But that can result in very large, very complex user stories.  I do see value in these user stories, and I tend to call them epic stories.  I prefer to take these epic stories and break them down into much smaller user stories.

One characteristic I try to keep in mind as I write a user story is that it should be small enough to be developed during one sprint.  So it is critical to understand the size of the sprints within your organization, since I’ve heard of sprints lasting anywhere from 1 to 6 weeks.  It also helps to get your development organization to provide you with some rough story point sizes, so you know if your stories are of an appropriate size or not.  For any story that has a point size estimate that is larger than the velocity of the team during a sprint, that story needs to be broken down into smaller stories.

What to do with Business Rules?

Another challenge is business rules.  With the project that I am working on, we have finished documenting the user stories, but they only tell part of the story.  They tell what the user expects to see, but not how the system gets to those results.  That is the role of the business rules.

Now, if the team were co-located in the same location, this is where the promise to have a conversation would come in.  During that conversation, the business rules can be vetted and discussed.  However, with the geographically dispersed team, much of this needs to be written down.  The story and the business rules can still be discussed, however, with cultural and language differences, having something in writing for team members to read through before the discussion and to refer back to after the discussion is a necessity.

But what is the best way to document these business rules?  Some can be documented with the acceptance criteria for the user story.  But sometimes there is the additional needs to get even more detailed than that, to get to the actual “if, then” statements.  Where is it best to document them?  I don’t have an answer to that yet, and much may depend upon the tool chosen to store the user stories.  But I am certainly interested in your experiences…how have you solved this problem?