Most bugs (in my experience, more than half of them) stem from poor understanding of context and requirements. A common problem for many development teams is miscommunication or misunderstanding of business requirements, which leads to many hidden consequences: False expectations of complexity Further problems with development quality More bugs Poor team motivation Communication problems To build any complex thing, the work should be divided into several achievable parts. Let’s define any type of task as a “Unit of work” (UoW). In software development, such a unit of work can be represented in multiple forms: DevTask, Chore, User Story, Task, etc. When trying to visualize a UoW life cycle to identify possible issues (by skipping UX etc), teams usually get the following challenge: A Product Owner (PO) defines UoW by writing a title and description within the product context. To simplify our case let’s say that the PO defines a triangle. After the presentation it’s clear for developers and the PO that UoW is to build a triangle. A developer who implements the described UoW imagines a triangle, but it looks a bit different from what the PO wanted to convey. The developer completes the development of the triangle and passes work for QA or UAT (User Acceptance Testing). At this stage, the engineer who verifies quality might understand the triangle in their own way. These kinds of scenarios result in back-and-forth migration of UoW which leads to delays in delivery, performance slowdown, team demotivation, or incorrect functioning of the application. Another common issue that leads to misalignment in teams is a lack of activity in grooming meetings. Usually, only the most proactive participants dive into the context when the Product Owner explains the UoW. As a result, we get into the Iceberg situation: a visible part of it, such as the title and a high-level idea of the description is clear to everyone, whereas a hidden part, which includes the context and unasked questions, remains vague. Meanwhile, the context is extremely important to be understood by all participants because it explains what should be done to bring value to users. An iceberg comparison helps to show how much of a context slips the teams’ attention What should one do to prevent missing context then? A proper description and presentation format of the UoW facilitates sharing the context. It enables everyone to comment on the UoW, add ideas on how to simplify a solution, and introduce a risk management and implementation plan. The main goal of the UoW is to put all participants into the same context, so every stakeholder becomes a participant in the business issue. During grooming meetings, a UoW can be appended or modified based on feedback and alignment. The User Story format fits best for adding new scenarios and sharing business context. However, it’s very important to keep User Stories aligned with pre-defined and high standards. Describing challenges in the User Story format is a sort of an art. Let’s look at what can go wrong and how to choose the way that eliminates such challenges. User Story Essentials A user story is an instrument for diving into the context of a development challenge. Compared to development tasks, which imply what should be done directly, User Stories describe a problem users have in detail so that the team can come up with technical solutions that solve it. When describing a challenge, it’s best to follow the we prepared. User Story template Find a step-by-step guide on how to write user stories that work below. “As-a” construct The following formula is used for giving the team members a user context: As a [role] I would like to [desired feature] So that [value / impact] Use this construct to describe the context of each stakeholder who faces the challenge to be solved. When team members will read it, they will look at the challenge with the eyes of the users and empathize with their needs, which is likely to help them generate fitting solutions. Example: AS A website customer I WOULD LIKE to get an additional offer during the buying process SO THAT I can find a worthwhile and satisfying offer that I actually need for my mobile device. Background information This section should include the way the challenge was discovered and why it is a problem. The answer to the ‘why’ question is important to show what motivates users to use the product in a certain way and where there’s a challenge. A useful practice is to record every decision or action that may be associated with this challenge there. Example: To increase the average cart, we will display a window with special offers that are fully relevant to customers based on their mobile operating system. 92% of our customers visit us from their mobile devices. We would like to increase customer engagement and make them feel that their experience is more personal as if they were coming to a real store. Scenarios Scenarios are formed and discussed by the Product Owner (or the product team) and the Scrum team. Usually, a grooming session results in describing scenarios of how the team will solve the challenge. Example: Pre-condition: the customer has added an item to the shopping cart from the ‘Product for Smartphones’ page. Scenario 1 — Displaying of the most relevant product. GIVEN THAT I’m a website user WHEN I added some product to the shopping cart THEN I would like to see an individual offer I would accept. See more scenarios in we prepared. the exemplary User Story Resources A user story should also include proofs, screenshots, or resources that may provide better context dive-in. Task tracking systems such as JIRA allow attaching all the necessary resources to a user story. A user story described following the steps above (‘as-a’ construct, background info, scenarios, resources) is difficult to mistreat or fail. The Common Vocabulary Leaving whether or not the story is ready to be implemented or released open to interpretation can cause confusion, frustration, and mixed signals that lead to negative user experiences and revenue impacts. To keep User Stories aligned with predefined standards, team members should speak the same language and agree on the criteria that bring standardization to the User Story format beforehand. (DoR) is a criterion that determines whether a User Story is complete and has all the necessary details for team grooming. Each team will have its own DoR since it largely depends on people and the context. Definition of Ready An example of a Definition of Ready: The unit of work should be written in the ‘User Story’ format. Acceptance criteria must be clear to the team. The team needs to estimate the story. The team should understand how to demo the features. Performance criteria must be clear to the team. (DoD) as a set of items that must be completed before a User Story can be considered done. DoDs that our teams form also include acceptance criteria, a set of test scenarios that are to be met to confirm that the software is working as expected. As a result, DoD aligns the team and reduces the chance of different interpretations of the same requirements. Definition of Done Communication Tips I strongly recommend keeping communication in comments and storing test cases associated with the User Story inside to ensure the focus of the team on the context. In case you will need to get back to the challenge and make one more iteration on it in the future, the User Story will become a rich source of information about it and actions made previously to get the necessary result. Another common pitfall is that the PO always knows more about the product and what should be done than the rest of the Scrum team. It’s on the PO to provide business context but to define the way for solving the challenge and clarify technical details is on the Scrum team. If the challenge requires the tech team’s help to list numerous technology-related details, the PO should communicate more and dive deep into the bottom of the ‘iceberg.’ Finally, the facilitator of the grooming sessions should make sure that every meeting participant is active. This allows for quality prioritization and a holistic discussion of the challenge. User Story Benefits Overall, there are many benefits that can improve your product development: No false expectations from the team Enable high development quality standards Fewer bugs Improved team motivation High software development standards Easier measured impact Improved trust with partners First and foremost, User Stories help describe the context unambiguously. The team stays focused and spends less time coping with the issue if they don’t need to find out any additional details by themselves. A motivated team usually leads to fewer bugs and rejects, and commits to more initiatives. A User Story helps to keep the team motivated by making the objectives clear and improving the results of their job, which allows them to get more positive feedback and achievements. Lastly, keeping all the information about an issue in one place allows for improved transparency and simplifies delegating challenges, not tasks. The results of such teamwork and the impact are easier to assess and commend. Techstack case At , we have been using the User Story format for many years. After looking closer at the current state and root cause analysis of multiple issues, we identified that our User Stories aren’t doing their job perfectly. Polishing User Stories and keeping communication around them in one place leads to amazing results. In our case, we had 5–10 bugs at 21 story points, which transformed into 0–1 bugs after we improved the quality of our User Stories. The Scrum team’s velocity became smooth and predictable. Failed commitments are now edge cases resulting from valid reasons, such as a team member’s sickness or vacation. The team culture also won in health and motivation. Overall, improved User Stories turned into a total win-win for all stakeholders: the team, product, partners, and users. Techstack Summary Communication is key to a successful and predictable development process. User Story turns out a round table for discussions over future achievements. Any agile ritual requires a deep and philosophical look at its concept and implementation. We are ready to share more . to learn more. expertise on communication enhancements Contact the team Written by Ivan Ieremenko , CEO at Techstack Also Published Here
