A few weeks ago, I conducted a survey poll in ModernAnalyst.com - Business Analyst Community group on LinkedIn to see what type of documentation the BA community uses for communicating requirements to delivery teams.
Well, no surprise that User Stories turned out to be the leader! And to me, the main reason they are so popular is that user stories are very business and end-user-friendly. They make us focus firstly on user needs/wants/desires, which makes total sense when building user-centric products.
Going with user stories in your software development process breaks barriers between IT and business, as the business may not only better understand and relate to the requirements documentation, but oftentimes suggest stories themselves and hence contribute hugely to the project implementation!
But then why do many teams still struggle with having user stories in their product development process? BAs keep saying, “Hey, those developers don’t read my stories!” or developers say they lack the details needed to build the system and demand more stuff to be put in the stories! Business stakeholders too may be confused by the lack of understanding of what exactly is going to be built in scope of a story, or on the other hand, they may be overwhelmed with too many technical details, complaining that stories are hard to read and review!
So, where is the sweet spot? And what do you and your team need to do to come up with great user stories — stories that will allow and accelerate the building of exceptional customer-centric products?
In this article, I'll share a lot of practical recommendations, including examples of a user story in Jira and a complete Definition of Ready.
Before we go further, don't forget to download the Scrum Cheat Sheet for IT Business Analysts that comes along with a free video tutorial!
What is a User Story?
In a very simple manner, a user story is an informal, natural language description of software requirements, written from the perspective of an end-user.
The key element here is the user perspective. The user story must be written as if stated by a real end user of the system. To me, that is exactly what makes user stories so popular – they break barriers between IT and business. Now software requirements may actually be written by the business stakeholders or, even better, requirements may emerge from collaboration between business and IT.
Structure of User Stories
While there’s no formal standard for how you want to structure your user stories, most often, you see user stories having at least two key elements:
Value Statement
The value statement is the core element of a user story, written from an end-user’s perspective. Most often, it is written in the format:
As a [User role / Actor], I want to [Description of desired functionality or a need], So that [Motivation or benefits of having this functionality].
Example:
As a registered website user,
I want to be able to see a list of the details of my past orders
So that I can easily reference my order history and initiate a re-order with the same items when needed.
Acceptance Criteria:
Acceptance criteria are another key element in a user story. These are very specific conditions that, when met, will allow the team to consider the work on the user story done. In turn, the stakeholders should accept the story as complete and delivered.
Example:
On the account dashboard, there should be a dedicated section labeled "Past Orders."
Each past order should have the following details: order date, order status, order delivered date, items ordered, and total amount.
For each past order, there should be a "Re-order" button that allows adding the same items to the current shopping cart.
Now, the question is, if the user stories are so great - they accelerate collaboration yet allow great flexibility - why then there’s still so much confusion around the proper use of user stories?
The Hard Truth
What I’m going to say in this section may, for some, sound controversial, like I’m going too far, shaking the Agile Manifesto and principles you see all over in books.
Here it is, anyway:
Lightweight user stories that contain no implementation details do not work in the modern software development world of distributed multinational teams, strict budgets, and tight deadlines.
Yes, lightweight stories might enable starting a conversation, sparking a brainstorming session, and perhaps quickly scoping the project or building a high-level product roadmap.
Yes, maybe! However, they do not serve the purpose of easing the way of communicating requirements to the delivery team, especially when the team is distributed, and you're working on a large-scale project. Instead, development teams will struggle with a lack of the needed information and will spend precious time clarifying details that are missing in the user stories.
Such user stories are never sufficient for the development, testing, or acceptance of the solution.
Meet INVEST and Gherkin
Two significant steps toward making user stories more executable and software-development friendly were the introduction of INVEST principles and the Gherkin format for the acceptance criteria.
INVEST is an acronym for Independent, Negotiable, Valuable, Estimatable, Small, and Testable. Refer to the article for more details on how to apply INVEST. These guidelines, though not yet specifying what the story should contain, set the right focus and act as guardrails to have in mind when writing and reviewing a user story.
Gherkin, originating from Behavior Driven Development (BDD), is a structured method of capturing acceptance criteria (AC) in the format: Given/When/Then. Instead of randomly listing numbered acceptance criteria, this approach is much more systematic and allows better structure that in turn makes it easier to understand what is covered by ACs and what is not.
Example:
For a portal registration user story, one of the acceptance criteria written using Gherkin will look like this:
Acceptance Criteria | Given | When | Then |
AC 1 - Successful registration | Given the user is on the registration page | When the user fills in valid registration information AND The user clicks the "Register" button | Then the user should see a success message AND The user should be redirected to the login page |
.. | .. | .. | .. |
.. | .. | .. | .. |
Check out this article for more details and comprehensive examples of using Gherkin for describing user stories.
Definition of Ready
Now, to actually get to the level of detail in the user stories, that will satisfy the development and testing needs, and also will be business-friendly, let’s take a step back, to what the user story is all about.
Because a user story is a "promise of a conversation", the best way to determine which user stories will work for your team and stakeholders is to actually involve them in the conversation, and agree on what the stories should look like. So, collectively decide on the actual format, amount of details, and how you want to capture and maintain user stories.
The result of such an agreement is a "constitution" of a user story, called the Definition of Ready (DoR). It comprises a list of criteria (think of them as meta-criteria if you will!) that any user story must meet to be considered "Ready" by the team. In this sense “Ready” here means, the story is ready to be taken into development.
Example of DoR
Here's an example of a Definition of Ready for an e-commerce software development project:
Each user story must meet the following criteria:
User story meets "INVEST" principles.
User story has a clearly identified value statement in the format "As a [user role], I want to [description of the need], so that [description of the goal]."
User story has clearly identified Acceptance Criteria in Gherkin (Given/When/Then) format.
A front-end user story must contain a reference to desktop and mobile screen designs.
User story is captured in Jira.
User story is approved by the business SME.
User story contains preliminary development estimates.
User story development estimate is small enough and is no larger than 5 story points.
There are no unresolved blockers and dependencies for this user story.
What's important is that another team and another project may have their own Definition of Ready that will work better for their situation. This flexibility is a great aspect of Agile, and Scrum in particular. In my other article, I talk more about the flexibility that Scrum gives to development teams, make sure to check it out.
Example in JIRA
Now, here’s an example that I put together of a user story captured as a ticket in JIRA.
As you will see, there are quite a few details in there and there’s a specific format that I’m using here. I start with the value statement, bring in a reference to UI mockups, and then describe acceptance criteria using Gherkin. I'm specifying what is out of the scope of the current story, to avoid any potential misunderstanding by the team or the stakeholders. Also, I’m listing out the dependencies that must be resolved before this particular user story can be even taken into development.
This user story meets all the conditions set by the Definition of Ready that I gave above, and, once approved by the business stakeholders, I can call this story “Ready”, bring it to the sprint planning, and pass it to the development!
Here’s how it goes:
Learn More
Interested in learning more? Download the Scrum Cheat Sheet - your all-in-one summary designed specifically for IT business analysts. As a bonus, it also includes a 10-minute video lecture on Scrum for BAs.
Conclusion
So, what is it that makes a great user story?
It’s a combination of factors, and the key here is to understand your team and your stakeholders' expectations regarding what they want to see in the stories. So, it starts with you, as a Business Analyst, getting to know your team and the client, and putting together the Definition of Ready. This definition will guide you further and set the tone and structure of the user stories on the project.
To facilitate the creation of the Definition of Ready, the best approach is to bring examples of what worked well on other projects – the more examples, the better. Get the product owners on board and allow for experimentation in the first few development sprints while you're working out the final approach.
I hope you'll find these recommendations useful and let me know how they work for you.
Thanks!
Comments