When User Stories are not enough

I recently attended an interesting webinar by MKS on why User Stories are sometimes an inadequate representation of requirements.  I thought it raised some excellent points, and certainly got me thinking.

Starting with a refresher on what User Stories were, the presenter Colin Doyle emphasized how they are NOT a requirements document.  Instead they are a placeholder for continued conversation on that particular piece of functionality and used especially for prioritization.  They are the tool through which requirements are communicated and discussed rather than delivered in the form of hefty requirements documents (see this excellent article from Mike Cohn on User Stories).  As Agile prescribes, in teams where face-to-face, daily communication is possible and the Product Owner and key stakeholders are readily available, the User Story format works very well.  Each story follows the INVEST criteria and are first and foremost independent of other stories, and the non-functional requirements or constraints do not dominate.  With each iteration, the product develops incrementally with the gradual evolution and folding back in to the project of the inevitable changes that will arise as the product comes to life.  If there is a need to review the requirements and see the “big picture”, then the User Stories in combination with Test Driven Design (TDD) or Behavior Driven Design (BDD) practices, should provide all the details you need.

Colin Doyle argued the point however that there are 3 key issues with this method, all centered around the scalability:

  1. Too many customers for the product resulting in conflicting requirements and a significant effort to understand customer environments and needs.
  2. Complex products with significant interdependencies, lots of exisiting requirments and the lack of a way to see the big picture easily.
  3. Large organizations where “scaling of face-to-face conversations is an N2 function (Brooks)” and may include offshore or off site teams.

Therefore he recommended the careful introduction of some traditional requirements engineering practices to help solve these issues.  In particular using modeling techniques such as use cases, decision

Use Case Model example
Use Case Model example

trees or event-response tables to get a handle on the big picture.  This will help the project in number of ways.  Firstly the developers will understand the full scope more clearly and so guide their TDD/BDD test cases and hence their code.  It will also help the Product Owner who may be unable to remain fully informed for large, sprawling products.  These requirements artifacts will also form the basis for a high level dependency analysis from which relatively independent User Stories and backlog items can be derived.  This should ensure that you arrive at a position with nicely traceable project, from the high-level product owner level down to the actual code.  The presenter was not arguing for a bastardization of the Agile philosophy by doing this requirements analysis upfront, he stressed it should be performed in a just-in-time, iterative manner, and the requirements artifacts changed and adjusted as the product develops.

I am receptive this approach.  I don’t think that the Agile community should unconditionally shun traditional requirements engineering practices as “old-school” and no longer relevant.  My concern with the approach is how easy it would be to slip in to a gather requirements up-front process.  The models and artifacts could become weights around the neck of the project requiring constant revision, whilst at the same time being the excuse why something was done a certain way.  I believe that the Agile methodology, with it’s primary emphasis on conversation over documentation, promotes an environment of “ask before you act”, to ensure that the correct path is chosen.  If there is too much documentation available, this can be viewed as the definitive answer, and reduce the amount of communication within the team and clarification with the product owner.

But that is not say I am ruling this out, and in fact I think I will try and incorporate this approach in to the next complex project I work on.  I think that so long as the culture of the team remains inquisitive and conversation intensive, these models can be good aides to discussion, just like user stories.

When User Stories are not enough

8 thoughts on “When User Stories are not enough

  1. Mark – Interesting comments you have. I’d be interested to
    go through the same Webinar. I wanted comment on 2 of the issues
    you refer to. 1) Too many customer’s for the product…significant
    effort to understand customer needs. — I propose addressing this
    through portfolio management and an allocated user
    experience/strategy team. That team has it’s own backlog of topics
    to research and understand in order to keep the execution team(s)
    informed on customer desires and considerations for user
    interaction. If an organization doesn’t have the luxury to allocate
    a team like that there are also 3rd parties like ForeSee that
    organizations can use to keep a pulse on customer
    needs/satisfaction. The output from either group is perfect for
    assisting product owners in prioritization as well as
    identification of existing user stories that should be modified, or
    new user stories that need to be created. 2) Complex products with
    significant interdependencies… — This actually aligns with a lot
    of the work I do on a day-to-day basis. I am essentially an
    allocated Alignment Analyst for a large retailer’s eCommerce team
    and manage a functional hierarchy of the site and do functional
    impact analysis of all the new feature requests that come through
    intake. Current project underway for me is to implement a tool for
    reporting on all the data I am managing so it can generate reports.
    It just so happens that this week I am going through indepth Agile
    training and strategy definition. I’ll be posting about ‘A Week of
    Agile Learning’ when it is all said and done with and would be
    curious to here your thoughts. Thanks again for a good

  2. Mark Tattersall says:

    Thanks for your comment Leslie. Regarding #1, I agree that team management is the key to scalability in the Agile process. In the same way as User Stories need to be as independent as possible, i think so to do the teams working on the same project, too reduce the interdependency and prevent the issue of waiting on somebody else before you can count your stories as complete. However that is not always possible, and allocating a UX or Strategy team that perhaps crosses these boundaries and pulls the customer needs together certainly sounds plausible.

    Check out the MKS website to see if the webinar is still available on-demand. I will certainly be interested to hear your thoughts following your Agile training and will keep my eye on your blog.

  3. Mark Tattersall says:

    David, not quite what I was saying, but I can see how you would interpret that. Every project is built on a set of assumptions, and that is what you believe the project is all about, but over time, and through iterative development and testing, that belief can be shaken or even turned on it’s head, as the product takes on a new life in the “real world”. So when I say constant revision, I was implying that the requirement artifacts (in this example) should be living documents and not decrees etched in stone. They should evolve with the product, and the product should be lead by the Product Owner and customers. Change should continue to be embraced, even if it breaks the models.

    That was more my line of thinking. Thanks for the comment.

  4. Hi Leslie,

    Please see the link I have attached you’ll find the on-demand webinar that Mark is referring to from MKS. Let me know if you have any trouble getting it…it was hosted by ADTMag.com, so you’ll need to register for it: http://www.mks.com/resources/data/multimedia/webinars/instances/adtmag.com-webinar-featuring-mks-agile-requirements-management-when-user-stories-are-not-enough

    Let me know if you have any questions – cmclean@mks.com

  5. Yes, change management is essential. The value of the models is impact analysis of change; it can show you how much is affected by a change, which is sometimes more than is first thought.

    This does raise another question for me, and that is the term “Product”. Software is most often a tool used by people in organizations to get things done. Is that a Product? Who is buying it? Most people don’t get to choose what systems they use at work; I am not going to say that is good or bad, it is just reality. The most famous (or infamous) thing about systems for decades was that they could automate people out of their jobs. So, it’s is question for me, looking for an answer.

  6. Mark Tattersall says:

    I use the term “Product” like I do “Customer”. The initial impression of these words is that you “buy” a “Product” or that you are a “paying Customer”, however in this context I see them having broader definition. The “Customer” is whoever will be using the resulting software, be they internal users or external consumers. The “Product” is the deliverable piece of software that will be used by the “Customer”, again whether that is dictated as the new tool of preference by an Organization, or purchased off the shelf by a consumer. The elements of choosing to use the product or what the result of the new product has on an Organization in terms of how they view their employees does not enter in to it, in this definition anyway.

  7. Mark,

    I have a particular aversion to “internal customers”, to me the only real Customer IS the one who parts with real money. That is the marketplace.

    An organization is not a marketplace. It is a team that needs to work together to meet its overall goals. Teamwork is cooperation, not negotiation. It is shared success, not measuring whether one unit made another unit happy.

    The worst I have seen of this is where budgets become “funny money” that one unit uses to “buy” from other units. I have seen units actually spend real money for outside products and services, because the internal price for the same was higher, and it was the funny money usage that bonuses were based on.

    I know, I know… IT is just so different than everyone else in the organization that the latter find it really hard to work WITH the IT unit. That is why that they prefer that IT work FOR them.

    IT should not want to be a supplier. Once IT is seen as that, the next thought is why does the org need to employ IT people when you can rent them. Companies change suppliers all the time; valued team members are an asset orgs want to keep.

    My father in-law was a skilled machinist. He worked for manufacturing companies, making the unique tools used on their production lines. If you had suggested to him that the line workers were his “customers”, he would have scoffed and said he builds what they need to do the work, not what they want or desire.

    This view of mine may seem like an over-reaction in the scope of this original topic, but words define us and the world around us. Beware what you call yourself for convenience, it will define you.

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s