User Stories: Not Just Agile Anymore

The User Story:  simple and elegant.

“As a ______, I want to _________, so that I can __________.”

Why must a user story only be used for Agile projects?  I was at a seminar recently where the speaker kept talking about user stories only in the context of an agile project.  Is there a thought that user stories have no value outside of the Agile methodology?  I say use the technique as a tool to analyze the needs and put those into whatever requirements format your organization uses.  Separate the User Story process to get at the details (personas and stories) from the output documentation.  Part of knowing and being comfortable in your craft is being able to evaluate the different tools and select the best one for you needs. Eliminating a whole set of tools because it isn’t the “right project management methodology” is an unnecessary filter to apply.  Use what you need to help you elicit, analyze and prioritize the requirements that you can document any way you see fit.

“As a Business Analyst, I want to analyze user needs, so that I can effectively document them for the project I am on.”

As business analysts, we are supposed to elicit the requirements for business processes and user needs.  There is a lot of value (and often requirements) in understanding the different perspectives of users, and User Stories are a great tool to get at and analyze those perspectives with their underlying needs.  We should not feel constrained to consider using them only on Agile projects, nor should we feel limited to documenting those discoveries and needs only in the User Story format.  Sure, there is value in the documentation format, but if your organization doesn’t “do Agile,” you might feel that you’ll never have a use for User Stories.  As Adriana pointed out in The future is Hybrid,

“We business analysts should be leading the discussion of what is effective for different types of software development projects….”

Using User Stories outside of Agile projects is one such example – if it can work for you, why not use it?

User Stories often bring up information you may not have thought about previously, which introduces additional analysis opportunities.   Whether you are working on a new user interface for an application or business intelligence reporting, truly understanding the different perspectives using personas for User Stories helps to ensure you haven’t missed anything and allows you to get at details that may be different between the personas that aren’t readily apparent until you’ve defined the different perspectives.  Agile, Waterfall or some other project methodology – understanding and documenting needs remains the same; the only real differences are the management and requirements output.

Another aspect of Agile’s use of the User Story is the points assigned to the stories to help prioritize the product backlog.  If you are using the technique outside of Agile, there is still value to you in assessing some kind of value for requirements prioritization – it can have the same effect on IT’s planning and the business owner’s decision making if IT is unable to address everything in the requirements.

The next project you are on, plan one of your early activities for requirements development as a short user story session.  You’ll likely have active participation to help define the needs which you can use to analyze the problem and put the results into whatever format is required of the project.  Use it as a tool to get what you need to complete your work – don’t feel constrained by the typical output from user story development to prevent you from using the technique.  So pull out those index cards or post-it notes and get your stakeholders and SMEs involved. You will all have more fun doing it!

>>Improve Your Requirements Writing Skills

Looking for practical ways to reduce requirements defects while also improving your requirements specifications? Check out one of our business analysis training courses:

At Bridging the Gap, we help you start your business analyst career and gain confidence in your business analysis skills.

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Comments

  1. @Jake, you’re right. “Effective” was not defined intentionally as I saw it to be the representation at the Epic level, that would be further broken down into smaller stories… had I mentioned that, it may have made more sense. You’ve called me out.

    @Stasy, I’m right there with you!
    One thing to consider, “best practices” don’t stay that way forever. They change over time or even discarded.
    User Stories came into prominence with Agile-run projects – and as you state, it isn’t the management of the project that should necessarily dictate what tools we as BAs choose to use to extract and analyze the information that is important to the success of the project.

  2. It seems to me that it’s another example of not loosing common sense in the ongoing trend of standardization and “stating the rules”. I mean here that it’s good to have methodology and best practices, but in the modern world and in BA profession in particular, one should be open to non-conventional ways. If user stories work in particular situation, no matter what’s PM model behind, why not use them!

  3. Your main point – that you can use stories on any project makes sense of course – but your story example is confusing to me.

    Ending the story with a “so that I can _____ ” seems to miss the point of the value or benefit. You probably realize that indicating the benefit or value is a critical element of the story – but others may miss that point since it is not noted here.

    The example story “As a Business Analyst, I want to analyze user needs, so that I can effectively document them for the project I am on.” continues on this point. What is the value of the document? What is effective? Effective could be clarified later with tests, but if we are talking about a decent story – no one would take that on at the high level it is at.

    I was also wondering if you clarify what you meant by “using story points to help prioritize the backlog” comment? How are you using points to do that?

  4. For me, the liberation came with using the technique and not worrying / bothering what the final artifact was going to be – the information needed was the same.

    @Tony, “unit of delivery” or “feature” is pretty much how I positioned it as well, don’t recall what phrase I used at the time. The PM may have used the stories from my stored notes for scoping since they didn’t want to see the User Stories themselves because “We [didn’t] do Agile”… even though they found a benefit to the effort.

  5. I’m with you on this one Steve! I introduced user stories onto a “non agile” project recently with great success. I broke the project down into stories and treated each story as a “unit of delivery”. We were able to discuss scope of each phase very easily by referring to the stories that were in scope. After a while I persuaded the team to start putting estimates against each story and then shared these with the stakeholders. They were immediately able to identify high-effort low-benefit stories and either de-prioritise them or remove them from scope completely.

    The business were overwhelmingly positive about this approach – finally we had given them the visibility and power they needed to effectively scope (and de-scope) the project phases.

    Notice that the benefits were to do with the user story as a “unit of delivery”, not particularly due to the “as a…” format. If your organisation is anti-agile (it’s not unknown), you can still get the benefits – just call your units of delivery “features” instead of “stories”!

  6. Thanks Adriana, David and Tim.

    A recent project I was on had some subtle but distinctly different user needs depending on the perspective / role of the user. Use Cases weren’t providing the needed perspective (ie requirements detail) for the subtle differences so I felt the need to try something different. Although I didn’t use index cards (colored post-its instead), the “magic” Tony Heap talked about in his article (http://www.bridging-the-gap.com/the-power-of-index-cards/) was right on! The participants got more out of the exercise and really started exercising some creativity for where the solution could go.

    If our job is to use our BA Toolbox to elicit, document and implement change to meet customer needs, we should feel free to use whatever tools we’ve got! 🙂

  7. I agree as well. In fact, I suspect we BAs create user stories without realizing it each time we attacking a new problem/project — whether it’s an “agile” project or not. The only way to learn a process or workflow is to step into the world of the user.

  8. David Manning, PMP says

    I am in total agreement with Steve’s comments! I’ve also found that business needs and situations vary, so it’s important to flex — adapting the best tools and techniques to be successful including: User Stories, voice of the customer (VOC), and requirements augmented with use cases and business rules. It takes maturity and confidence to adapt and adopt methods as-required… applying art and science to be successful.

  9. Great point, Steve!

    I constantly borrow from agile practices — user stories, Kanban Board to organize stories and other work items, and many other agile elements whenever they prove to be useful even in a non-agile project.

    As I wrote in another article for Modern Analyst (http://modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/2082/Agile-vs-Traditional-Part-III-Winning-Through-Integrative-Thinking.aspx), I’m on the team of the “optimistic model seekers”, people who don’t believe there is a right answer, just the best answer available now. Your question fits perfectly this mindset: “Why must a user story only be used for Agile projects?”

    Kudos for encouraging the readers to experiment with different techniques — this is what allows us to constantly develop better models for analyzing business problems and determining the best solutions to address them.

Before you go, would you like to receive our absolutely FREE training?

(No formal experience required.)

21689
21690

Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.