In some of my previous posts, I’ve been describing what Agile is and the usage of some Agile tools, from the high-level. In this post, I’ll focus on an important unit of Agile software development process, which is User Story. User stories are representing smaller units of work, that needs to be implemented in the sprint.
Starting the project with the Agile methodology you will start with the creation of Product Backlog, where you will be adding Product Backlog Items (PBI’s) with the description which will be usually written in user story format.
This might seem like a simple job to do, but you would want to consider some basic rules and recommendations before starting adding the description of PBI.
Definition of user story
Considering working with Agile methodology, a user story is a high-level description of the PBI’s requirements in the Product Backlog. It has to be the right size, not too detailed and not too abstract and it has to have just enough information that development team can start with the estimation of implementation effort.
A user story is expressing the small piece business value, deliverable in one sprint. Deliverable doesn’t mean just developing the PBI but also testing in the same sprint. So, it has to be small or big enough to be developed and tested in the same sprint.
My high recommendation for the creation of User Stories would also be, to make the meaningful, short, but yet explanatory title of the user story. Considering that we are developing a game, I would highly recommend avoiding User story titles in this format:
- Game rules
- Game characters
- Main menu
Rather than having such titles, I would personally prefer to use User Story titles, as follows:
- Develop basic game rules in xy format
- List all available game characters
- Display main menus in navigation bar
Another example of the Agile backlog is shown on the image below. This backlog was built for e-commerce purposes and you can understand from the image below that each PBI is a separate story, which means that it can be implemented without any dependencies on other PBI’s.
Format or a template for User Story
There are three very important questions, which we should consider covering them when writing user stories:
We need to ask ourselves for who are we building this product or service. Who will be the actors using this product or the service?
What is it that we are actually building or what are the user’s needs for this product or service?
This question is covering the goal of the feature that we are building. We need to ask ourselves why does the user need this feature and why we are building it.
The user story needs to cover all three layers or questions in order that team understands for who, what and why they are building the features. In this way, the team can focus on providing a business solution to solve users problems, rather than just writing the code.
Although there is no official template that Agile uses or forces, there is a common and widely used template to write a good user story, that uses the following form:
As a <role> I want <something/function> so that <goal/benefit/value>.
Let’s try to take a look at two different examples, using the same template for the same task:
Task is: Implement Trello Integration with VSTS
A poor example of a user story, with an attempt to respect such template would be:
As a user, I want VSTS to integrate with Trello so that I can see the team’s board.
A better example of the same user story:
As a user, I want VSTS to integrate with Trello so that I can see on boards when certain events happen in my team project.
In example below, you’ll see the User Story in the PBI, which is part of an existing Product backlog. On the image, you’ll see User Story in the Description field, and below the Description field, you’ll see the Acceptance Criteria field. Acceptance Criteria are another important part of User Story, but I will not cover them in this post. For now, just consider them as additional guidelines for User Story implementation.
A Very important concept, which everyone writing user stories should be considered, was developed by Bill Wake in 2003 and it’s known under acronym INVEST. All well-formated user stories are respecting INVEST concept.
I – Independent (Can the PBI stand alone, without any dependencies on another PBI?)
N – Negotiable (Can it be changed and adopted, without any breaking any explicit instructions?)
V – Valuable (Does it have a value for the end user?)
E – Estimable (Can the team estimate the size of it?)
S – Small (Is it small enough to be designed, coded and tested within the sprint?)
T – Testable (Is testing possible from acceptance criteria and DoD?)
Most common mistakes or misconceptions
There are many details about how to write a good user story. As explained in previous lines of this post, it might seem a very easy job to write a user story, but many Product Owners, even the ones with good backgrounds and experience, are making some of the most common mistakes, which are leading in the opposite direction, as we would want to. Here is some of the most often mistakes:
- Too detailed user stories, where I believe that most of the Product Owners do this with very good intention, but at the end, they end up with huge business documentation, which is not at all what is needed in order to reach a good business value for the customer or end user.
- Technical tasks are not user stories. In many of my projects, I saw examples where the developers are writing user stories for their own scenario, such as: “As a developer, I want to conclude the development of my code, so that I don’t need to come back to the same issue”. This is leading to having non-working software and back to the waterfall approach.
- Filling the blank spaces in the template. This is another issue that I’ve noticed while participating in different projects. People usually just want to finish their tasks and move on. Finishing the task as quickly as possible usually means having poor output, without including the business value and just trying to fill the template with anything, even if it has no sense.
User stories might seems a very small unit in Agile software development cycle, but they hold a very big weight for delivering quality and valuable product to the customer or to the end users. In this part of development, as a good Product Owner, you would really want to consider putting the good effort in producing a well designed and quality backlog, containing just the right level of the user stories details, as this will be your basis for producing what business needs. It’s definitely not an easy task and you will need to have a good balance between sense and details.
Please note that there is still so many other important parts of a user story. This post is just describing the main points and guidelines how to start writing good user stories, but there is even so much more to it. When we start adding more details to the user stories in grooming sessions, we start to define acceptance criteria and even wireframes, which are not covered in this post. All this parts are also very important parts and good Product Owner should know them by heart.
Thanks for reading and feel free to leave your feedback or questions in the comments section below!