• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

The Most Important Part of A User Story

The last couple of years has seen a wholesale shift in development methodologies among the Fortune 1000 companies from Waterfall to Agile.  It is not an exaggeration to say that the Agile revolution that has been brewing in small companies, startups and web companies for the last decade and a half has finally arrived in the development shops of mainstream corporate America.  At Seilevel we experience this shift daily.  Almost all of our current customer base has made a shift to Agile in the last year or so.  And every conversation I have been in, with prospective customers in the same time period, has been around moving to Agile.

As a practicing consultant, I get to experience this transition first hand.  I work on a team for a customer who is transitioning to Agile after spending the last two and a half decades (yes you read that correctly, decades) as a Waterfall shop.  And every team we interface with is making the exact same transition as we are.  The old staples of the Waterfall world like the Business Requirements Documents, Software Requirements Specifications and Functional Specification Documents have been replaced with Agile Requirements Documents, Epic Stories, Backlogs and User Stories.

Of all the artifacts created to assist the Agile development process, the one that stands out above all others is the User Story.  User Stories are ubiquitous.  They are on everyone’s lips.  Project Managers want to know when the stories will be ready for a sprint, analysts are writing them, scrum masters and product owners are prioritizing them, developers are consuming them and testers are desperately trying to understand them so that they can evaluate what is being delivered to them.   User Stories have replaced requirements as the lingua franca of the development community.

As this transition takes place from traditional requirements statements to User Stories and Acceptance Criteria, there is one fundamental misunderstanding of User Stories that I see in almost every team I have seen in action.  User Stories are treated exactly like requirement statements by the people creating and consuming them.  Stories are written, loaded to the requirements management system, prioritized, pulled for development, tasks defined and taken up for work.  All of this is as would be expected in any Agile workflow.  But there is one thing that is consistently given short shift is a critical and integral part of the User Story – the conversation.

A User Story is at its heart, a promise to have a conversation.  The conversation is what gives context to the story and the acceptance criteria.  The conversation takes the place of the detailed requirements statements that were created to support Waterfall development efforts.  The compartmentalized nature of Waterfall development necessitated very detailed requirement statements that were the means of communicating at a granular level exactly what needed to be built.  In Agile, we eschew the effort it takes to create detailed requirements and replace it with just in time communication that clarifies for the developers the pieces that are not explicitly detailed in the User Story.  If these conversations are not taking place continuously throughout the development process, then Agile will not work as well as expected.

This is part of the growing pains of shifting to Agile for traditional Waterfall shops.  Continuous ongoing conversations about the software being built is simply not part of the DNA of these organizations.  Requests for clarification are misconstrued as criticisms of the quality of the User Stories written by the analyst.  This leads to a desire to write more ‘detailed’ User Stories.  Similarly offers to explain the User Stories are misunderstood by development as an inability to understand the requirements implied in the User Story or blamed as poorly written documents.  Conversations are an integral part of the User Story without which the benefits of shifting to Agile cannot be realized.

Leaders who are at the forefront of transforming their organizations’ development practices by implementing Agile must pay careful attention to this problem and ensure it is addressed.  Everyone must understand that conversations must happen and are an inherent part of a User Story.  There must be no stigma associated with having to explain a User Story or asking for clarification.  This is expected behavior and not an indication of incompetence on the part of either the analyst or the developer.  These conversations should be encouraged and people must be rewarded for engaging in them.  It is also essential to train people on how to have these conversations in a productive manner around the User Stories.  An inordinate amount of time is spent on training people to write ‘good’ User Stories but almost none on how to have conversations around them.  It is impossible to write User Stories that do not need conversations.  Simply put, a conversation is the most important part of a User Story.

7 Responses to The Most Important Part of A User Story

  1. Lorie K February 11, 2016 at 2:00 pm #

    Good article.
    I am curious what an Agile Requirements document looks like….trying to help our transition as well. Can you share?

  2. edward February 12, 2016 at 11:01 am #

    Ajay, great story!!

    with respect to these two points:
    ” If these conversations are not taking place continuously throughout the development process, then Agile will not work as well as expected.”
    and
    “Simply put, a conversation is the most important part of a User Story.”

    in my opinion, the *second* most important part of a User Story is that minutes or decisions or notes or drawings or whatever created during those conversations are RECORDED for future reference [in client reviews, testing plans, acceptance plans, training development, etc.].

    having those conversations and *not* recording any of the information or decisions made during those conversations is as bad, if not worse, a problem as not having the conversations. better to rely on a recording than our memories.

  3. Ajay February 16, 2016 at 12:02 am #

    Lorie, thanks for your kind words. Please reach out to info@seilevel.flywheelsites.com for a sample of an ARD. They should be able to help you.

  4. Ajay February 16, 2016 at 12:04 am #

    Edward, I agree with your viewpoint on recording the key decisions, artifacts, etc. generated by conversations. You are right, what is the point of great discussions if everything is forgotten 30 minutes later? :-).

  5. Christy February 16, 2016 at 4:40 pm #

    I think this is a great description of one side to which the process pendulum needs to swing. Just like we have visual vs linear learners, in the 15 years I have been writing requirements I have found a pattern of social vs antisocial software developers. Neither is wrong; the social developer will need conversation to round out his understanding, while the antisocial developer will depend heavily on detailed documentation. To leave out either, in my opinion, is to leave out a valuable skillset (I actually am of the opinion that the antisocial developer, on average, tends to write more optimized code)! It may be that consistent process dictates that one form or the other must be emphasized, but, as in politics, I find that orgs often toggle back and forth, trading one set of strengths for another in the quest for best practice.

  6. Ajay Badri February 16, 2016 at 5:39 pm #

    Thanks Christy for your insightful comment and for sharing your real world experiences. One thing that I should perhaps have made clearer is that conversations are not necessarily verbal or in meetings. Modern conversations take place via messaging platforms like Skype, text messages, email and social media conversations. No matter what means of conversation are practical and suitable to the users social comfort levels (for example, anti social developers may not want to talk verbally in meetings or one on one but willing to chatter endlessly on Skype), the only point is that they need to take place.

  7. Linz April 12, 2016 at 9:08 am #

    I totally agree with you that continuous ongoing conversations are important during the development of the product. There should be conversations even before the story card is written. These conversations would also help in the development of the story cards. At the same time I feel clear and concise requirements even though not detailed needs to be written. Looking at the requirements, the developer and the tester should have clear understanding of what needs to be done. Depending merely on conversations might lead missing some key points which was discussed with the business users. This especially happens when you are working on multiple projects with different business users and there many meetings to discuss the requirements of the project. Like you mentioned, conversations needs to happen on those things which are not explicitly written in the story card.

Leave a Reply

Your email address will not be published. Required fields are marked *