Table of Contents
You may wonder who has the most influence on quality in software development. Which role is more important than the other? What is the relationship between them? When we talk about agile teams, the Product Team (PT) and Development Team (DT) are one of the most important roles and user stories are the bridge between each team. They have different responsibilities but the same purpose: deliver what the end-users/customers want and ensure they are satisfied at the end.
THE IMPORTANCE OF USER STORIES
User Stories are delivered to the DT by Product Managers/Owners, and to build the product, the DT will have to implement what they received. Roles and responsibilities of each seems quite clear, simple and easy, right? Well, not really. The development team usually faces the following problem: they don’t know how to implement what the user stories say. Sometimes you can see PT and DT almost going through the “armageddon” because of the quality of the user stories.
1 . The user story doesn’t really explain insights and expectations of the end-user/customer
As its name says it, user stories tell a story and it needs to be real. It describes in words how the end customer uses the product. So finding out and understanding why customers would want to use the product is important before starting to write a user story. You can’t just create it by guessing what the target wants or by just following your own perspective. You absolutely need to take some time to get all the information and to avoid producing vague user stories.
2 . Got confused between user stories and tasks
Confusion between user stories and tasks will lead to wrong product delivery; the product team will write tasks instead of user stories. It will limit the team’s ability to innovate, accelerate and try new approaches.
- Again, a user story is described by the PT and implemented by the DT team. It delivers visible value to customers while a task is represented by development activities and does not provide value to end users.
- Product Owners need to focus on building the right product for the end-user and will have to create proper stories. After that, the tech team who’s in charge of building the product right, will tend to clarify those stories into tasks.
- User stories give the developers a clear idea of what they need to develop and why they need to do it. It involves many activities (e.g., programming, testing, database design, user interface design, analysis, etc.) and therefore tasks are restricted to a single type of work and help to make sure that the developer working on it has a well defined activity that needs to be done.
- A user story is hard to be fully developed by a single person. It is the result of a collaboration between PT, QA, DT & Designers. It is the result of team efforts. In contrast, a task is written by the team such as “code this, write unit test first, design that, create test data for, automate this”. These activities tend to be done by one person.
- PT needs to focus on the right user and goal to describe, while DT breaks it into tasks and how to accomplish it.
3 . Development team gets annoyed because of bad user stories
A good user story will help the team build a great software and make your customers happy, while the result of bad user stories will lead to a poor product quality and ultimately customers that complain.
By following bad user stories, the DT builds something that is not what the customer really wants and leads to missing deadlines, failed sprints and waste of time to re-build or fix it. So here are the main effects of bad user stories:
MISSING DEADLINES because
- Takes too much effort to figure out what is really meant by the story
- Need to do additional research before the work can start
- Wait for external dependencies to be cleared
PRODUCT & QUALITY ISSUES will affect to team’s performance because;
- Back-end infrastructure is built with nothing to show to the customer
- Build something only to discover that it is not what the customer really wanted
- Overly detailed and descriptive stories will not allow developers to use their creativity and their technical skills to build the best possible solution for users
- Lack of clear acceptance criteria leads to wrong definition of task and wrong estimation
TIPS TO BUILD BETTER USER STORIES
By now, I think I made it clear that it is better that PT, DT or anyone related to the product features can recognise whether the provided user story is good or not before starting implementing it. Below are some key techniques that could help build a better user story.
- Focus on the right end-users/customers, making surveys or interviews to understand them. Always put yourself in the role of end user’s shoes (customer, administration, sales people…) then try to understand what outcome you want, why you want it, and how you would want to use the product to achieve it so that your user stories will go to the right way.
- Try to start a user story by having a conversation with the involved team (QA, development team…) to get more questions and more answers. The more ideas you get, the better user story you can write.
- Create user stories with important criterias: understandable, right-sized (neither too narrow nor too broad), consistently structured (use Epics, Themes and follow INVEST principles), easier to review, flexible to fix, testable, and finally able to be Agile.
- The rule of thumb can be a good method to add the acceptance criteria
To conclude, don’t underestimate user stories, in fact a right user story enables the team to move fast, develop working software as quickly as possible and most importantly: the team can deliver business value to customer/end users.
