The Community Blog for Business Analysts

Seilevel
Seilevel

Challenges with User Stories

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?

Let us know, or check out other posts. http://requirements.seilevel.com/blog/2010/10/challenges-with-user-stories.html

This entry was published on Nov 22, 2010 / Seilevel. Posted in Business Rules, Systems Analysis, Business Analysis, Agile Methods. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  1 members liked this article

Related Articles

COMMENTS

Naveen Rawat posted on Wednesday, December 8, 2010 12:07 PM
User stories:
I think there is no structured set of rules which says that stories must be of these many words, On the First hand it is important to have a process as to how the story management is going to govern hence that process need to be chalked.
I don’t believe that story should be huge (it should be the Epic story) in my opinion (I may be wrong) infect the stories should be small the one stating the functionality and easy to maintain.
Before writing story it is important to understand how different teams are organized in the project (organization) and what all teams are there along with there responsibility.
(Good to Know)You need to have a process which must tell how there teams are going to coordinate and what point these teams are going to coordinate, the flow of information and the sequence of information flow.

The Number of teams that can possibly be there in the project (assuming process team has already contributed)
 e2e teams - these are the teams who interact with end customer and get the generic requirements out impacting e2e Arch
1. e2e BA team
2. e2e solution Design team

 component teams - Precisely these are the system experts because they concentrate on individual component in the e2e Arch
1. component BA team
2. component solution Design team
Structure that can be followed:
Its always better to have a customer demand (Just a liner sought of thing or more at a high level) there can be single demand for an area or multiple demand but not too many for the area (demand at high level must state as what customer want and its objective) and hence a demand story for that to be created.
The Demand should be drilled down to another level which should be at a customer experience level (non system specific - they have to be a pure requirement not a technical mapping)
These CE's can be as many as required to support the demand: caution: it is advisable not to club the functionalities it would rather be better to create two stories instead of one (if at all there is a scope or possibility)
Point to remember, these stories impact e2e Arch, hence to understand those and to solution those e2e solution team is required, here comes the participation of e2e solution team

This solution team understands the requirements from e2e BA team and chalk out the e2e solution stories for e2e requirement (these are also the form of user stories). So one customer experience story should be source for one or more then one e2e solution story.
Once done then component BA/ solution should pick there required area and from there they should start writing stories for there component and hence component design stories (here comes there real granular level).
So from one demand is parented to 4 to 5 level hierarchy
Only registered users may post comments.


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.



Modern Analyst Blog Latests

Jarett Hailes
Jarett Hailes
As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
2 Responses
Howard Podeswa
Howard Podeswa
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
15 Responses
Adrian M.
Adrian M.
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN
1 Responses
Copyright 2006-2019 by Modern Analyst Media LLC