Updated: Jan 2
Did not write a story well, did a function wrong;
Made a mistake in a function and messed up a project;
Messed up a project and lost a customer;
Lost a customer and broke a company.
There are many volatile, uncertain, complex, and ambiguous requirements in the software field. Customers don’t know what they need while the developer doesn’t know what to do. Therefore, Agile add the new role, “customer”, into their system, ensuring that the development team can communicate with customers effectively and delivers the products that customers really need.
User stories are easy to tell, but it is not easy to use them well. Teams may fall into various traps if they are not careful. So, what are the common pitfalls of user stories? How to effectively avoid these pits and use user stories efficiently?
The next two articles (this article and the next one) will discuss the seven pitfalls frequently encountered in using user stories in Agile management to help readers avoid these pitfalls in the actual use of user stories, which can also help readers to use user stories better and more efficiently.
Trap 1: When will you use it?
A user story is a record that describes “what a person uses what function in the software to achieve what purpose or gain what benefit”. To implement a function, you must first ask who it serves, then think about why users use this function and finally think about how to implement this function.
So, which things are suitable for using user stories? Generally speaking, a user story is a simple format used for business value statements, so it is suitable for various requirements directly related to users, especially software functional features.
User stories can also be used to describe, track, and confirm some items that the team needs to put in the time to complete. However, it must be clear that these matters can’t deliver actual value to customers. Strictly speaking, they can’t be regarded as user stories, but just records of a certain task.
There are also some items, such as the construction of the infrastructure, which is the basic work to be done for the delivery of the project. Of course, it is no problem to use “user stories” to track them. However, the users of these tasks are technicians themselves. It is more convenient for the technical team to communicate and communicate based on the common technical language.
Guide to avoiding pits: For each to-do list
First find out who the user is, then think about why you want to do it, and finally determine what to do
Use user stories for user-related needs
For technical issues, use a common language that the relevant personnel can understand
The following requirements or items are better described, tracked, and confirmed by user stories:
Write documents, user manuals, and other documents
Defects reported by users
Aiming at the uncertainty, knowledge acquisition requirements such as prototype, concept verification, experiment, and probe are obtained.
The following items can be described in relevant language:
Function and code problems found internally
Technical debt such as restructuring
Trap 2: Who will write it?
The next iteration is about to begin, but the user story has not yet settled. There are only a handful of user stories in the product to-do list, which is not all the work of the next iteration. Who should write the user story and when should it be written? The team has no consensus. Everyone feels that it should be written by others, not their own business.
User stories are the description and communication method of the team’s needs. So, who should write user stories? There are usually no strict rules about who should be responsible for writing user stories. The usual principle is that whoever is close to the user is given priority and can also be authorized to others.
User stories are usually written in business language, so it is best to write to them by customers or product owners. If users are not willing, the development team can write user stories. However, user stories written by the team, especially acceptance criteria, must be confirmed by the customer or product owner. The prioritization of user stories and to-do lists must also be determined by customers, such as the product owner.
The development team can write user stories through interviews, questionnaires, observations, and story writing workshops. Story writing workshops are one of the most effective ways to quickly create user stories, which can be held before starting each release plan.
Guide to avoiding pits 2:
The responsibility of writing user stories is reduced in turn
Customers and users of the project
Market and business personnel in the project
A product owner or agent product owner
Business analysts and testers familiar with users and business in R & D team
Technical members of the R & D team
Trap 3: Who are the users?
The technical team is prone to fall into the “technology-centered” thinking, conceivably shut up and assume that what they understand is what users need. But it’s not clear who the users are.
Sometimes, the user that the team thinks is too singular and abstract, and the user range is too large and abstract, resulting in unclear definitions, such as “salesperson.” On the other extreme, user roles are too fine and too many, causing confusion in the team’s precise understanding of requirements.
Sometimes, the developed software may be used for other software or systems, such as middleware, microservices, etc. A complex system contains many independent but closely related software and components. Each part is the component of the whole software or system and has its own upstream and downstream interfaces. In addition, different components of the team’s own internal system may schedule each other. Therefore, it is difficult to define clearly “human” users for such systems or components. Teams are prone to fall into technology-centric thinking, focusing only on interfaces, forgetting that the upstream and downstream systems and different parts of themselves are actually “users”-system users.
So, how to define user roles precisely?
Guide to avoiding pits 3:
Teams can use design thinking tools for user research:
User experience map
For system users, you can try:
Define upstream “suppliers” and downstream “consumers” users, which are software systems, components, or interfaces.
“Suppliers” and “consumers” should strengthen communication and coordination: clarify each other’s needs and dependencies, such as interface types, data formats, and other technical parameters.
Integrate the requirements of system users into backlog management: propose requirements from downstream to upstream, write user stories, define technical indicators, put them into the backlog list of the upstream team, carry out unified prioritization, and include them into the release plan and iteration plan.
(To be continued...)
Please stay tuned for the next article “How to make good use of user stories in Agile? (Part 2)”.
Keywords: Agile, interdependence, acceptance criteria, INVEST, development, checklist, Delphi method, acceptance criteria, team commitment, agile methodology, agile method, agile project management, agile manifesto, agile definition, agile with scrum, agile scrum, agile development, agile certifications, agile meaning, agile software development, agile principles, agile vs scrum, agile scrum methodology, what agile methodology, agile synonym, agile training, what agile project management, agile development methodology, agile team