Developing software is not about blindly writing strings of code. There has to be a reason behind its development else nobody will bother using it, let alone buy it. Developing software is not an easy task. It involves extensive planning, hours and days of coding, brutal testing, and finally, launching. However, if the software is not needed in the first place, all the above activities would be futile and wastage of time and money. This is the reason why user stories rock.
Defining User Stories
A story told from the perspective of a person who wants something and what they wish to achieve from it is what user stories are all about. As a part of the agile approach, the user stories drive the focus to talk about the requirements rather than just writing them. Simply put, user stories are modest accounts of a feature expressed from the viewpoint of the user who requests the new capability.
The typical template followed in this context is:
- As a (User) – it’s really about who wants it.
- I Want (Goal) – what the user wants the system to do.
- So That (Reason) – why the user wants the said capability or functionality.
Example
- As a user, I want to upload eBooks so that others can read them.
- Similarly, as an administrator, I want to approve eBooks prior to uploading so that I can monitor their suitability.
Who Needs Them
Three main parties need user stories. These are:
- Project Sponsors – The stakeholders need to validate the need for developing new software. The user story provides a place to start a conversation and convince them about its necessity and viability.
- The User – Understanding all the needs of the end user becomes more structured with the aid of user stories. It facilitates the documentation and discussion of all the features requested by the end user.
- Project Owner or Manager – Project managers benefit the most through user stories. This is because development projects are usually large initiatives which can be easily prioritized through user stories. It provides a non-technical, crisp summary for the product team to choose the importance of a feature.
Need For User Stories
User stories are not just extra work to keep the teams busy. They serve several benefits which include:
- Drive The Focus On User – In the hustle and bustle of things, one tends to lose focus on why they started in the first place. The user needs to become lost somewhere in between, and other activities take precedence. In such a case, having a user story drives focus on what the user wants. It like a to-do list where you keep checking each box as you move forward with solving user problems.
- Enable Collaborations – A user story clear defines the end goal, which is what the user wishes to achieve through the desired functionality. As a team, you can collaborate and work cohesively to choose how best to proceed, serve the user, and meet the final goal.
- Create Momentum – User stories create an understanding of needs. As each requirement is satisfied, one at a time, the team enjoys a small win and moves on to the next level. Winning these small challenges keeps the team driven and creates momentum to move ahead with full dedication.Drive Solutions – A single user story has the ability to lead to multiple scenarios for the business analyst. This allows the analyst to analyze all the possibilities and choose the one which best suits the user expectations and business goals. Stories embolden the team to think creatively and critically to meet the desired goal.
Who Writes User Stories?
Typically, user stories are the responsibility of the product owner. He has to ensure the product backlog of Agile user stories. However, it does not mean that only he has to write them. They can ideally be written by anyone involved in the project. One characteristic of a good Agile product is that, sooner or later, all members of the team would have a user story example written by them. Important is the key stakeholder’s involvement in discussions and not who writes the stories.
When Are User Stories Written?
Ideally, user stories are written during the course of the Agile project. The teams come together to create a product backlog to describe, in detail, a functionality which needs to be added during the course of the project. Some Agile stories are epic and need to be broken down into smaller and easy to understand stories that fit better in a single iteration. Furthermore, fresh stories can be written anytime and added to the product backlog by anyone.
Characteristics of Ideal User Stories
The acronym INVEST best describes the features of an ideal user story.
I – independent
N – Negotiable
V – Valuable
E – Estimable
S – Small / Sized Appropriately
T – Testable
Tips To Write User Stories
While writing user stories, consider the following:
- Define ‘Done’ – The definition of ‘Done’ should be absolutely clear. Completion of the outlined task by the user is ideally the end-point but do not leave it to assumption. Clearly, define it to avoid mistakes.
- Multiple User Personas – If there are many end users, create multiple personas to address all their requirements.
- Feedback – listen to what the users have to say. Their feedback may help you capture more opportunities.
- Time – software development works within strict timeframes, so don’t overlook the time aspect while writing a story.
Closing The Debate
User stories behind a product help justify its viability. These stories provide the necessary background when pitching to sponsors or backers. Additionally, they also chart out the future course of action. What may seem as a futile activity is indeed very useful. It helps break the big picture down to smaller ones, which are easy to understand and execute. The software development efficiency is greatly dependent on how well the backlog of user stories has been built. Good user stories paint the picture of user expectations and what they wish to achieve. These stories are the stepping stones to the success of the software. Ultimately, the software is useful only when it lives up to its expectations.
