Creating tickets is a collaborative effort between me, the engineers, and the designer. Once I have described the issue and provided wireframes and flows, the engineers take over to create the actual tickets based on their technical expertise. This ensures that all aspects of the issue are properly addressed and implemented in the ticket creation process. How do you create tickets? Do you do it yourself, or do your engineers do it once you’ve described the issue and the wireframes and flows that the designer has provided?
14 Likes
In our organization, creating tickets for issue resolution is a collaborative effort between multiple teams. As the product manager, I typically start by describing the issue and providing wireframes and flows to the designers. Once the designs are ready, our engineers take the lead in creating the necessary tickets to address the identified issues and implement the required changes. This approach ensures seamless coordination between different stakeholders and streamlines the ticketing process for efficient problem-solving.
By involving multiple teams in the issue resolution process, we are able to leverage the expertise and perspectives of each team member, leading to more comprehensive and effective solutions. Additionally, this collaborative approach fosters a sense of ownership and accountability among team members, as everyone is actively involved in finding and implementing solutions.
13 Likes
It depends significantly on the nature of the product and the team dynamics. It’s frequently more effective for the PM/PO to stay at the higher level (Epics in Jira, for example) for highly technical products (services, infrastructure, etc.), but to collaborate with a tech lead to create the stories that meet the objectives and specifications specified in the Epic. There are several requirements to make this work, such as collaborating with engineers to develop backlog triage, but in my opinion, when done correctly, it’s much better (having tried it both ways many, many times).
I’ve seen it work well for PMs and POs to write the stories and have engineers handle the subtasks for less technical products (UI, etc.).
Setting expectations with your team by addressing that question collectively is more crucial. If a PM writes every story, there’s a risk that they will become a backlog janitor and lack the time and resources to truly offer the value they are hired to add, which is to keep the team moving forward and fulfill the needs of the client. Instead of the true value of keeping the team focused on results for your customers and business, your perceived worth becomes the tangible contribution of a tale.
Having said that, most businesses find this to be a very dysfunctional area since project management, program management, operations management, and so forth are all closely related to the role of project manager. Because they don’t know what you really do, people assume that the only thing you contribute is writing stories. That overlooks the value you provide when you perform the product properly.
12 Likes
It’s explained really nicely here. In my opinion, Usually, I submit tickets for more UI features. similar to a fresh search filter. Submitting tickets for UI features, such as a fresh search filter, is something I often do. I find that it greatly enhances the user experience and makes navigating the platform much easier. Additionally, these additional UI features can also help improve overall efficiency and productivity for users.
However, I am more inclined to supply the business requirements that guide technical design if we are discussing a modification to the indexing process. Engineers then draft the tickets. This allows me to provide a clear understanding of the desired outcome and ensures that the technical implementation aligns with the business goals. By involving engineers in the ticket drafting process, we can collaborate effectively and make informed decisions regarding the modification to the indexing process. This approach helps streamline communication and fosters a more efficient development process.
11 Likes
Product writes 90% with Dev writing subtasks when needed.
Dev writes 10%: library updates, most SSO stuff, backend refactoring, etc.
10 Likes
The ticket is written by the product manager. After that, the engineering team grooms them. The engineers ought to then have everything they want for independent work. Once the engineering team has completed their grooming process, they can proceed with breaking down the ticket into smaller tasks and assigning them to individual team members. This ensures that each engineer has a clear understanding of their responsibilities and can work independently towards achieving the desired outcome. Additionally, this streamlined workflow allows for efficient collaboration and minimizes any potential bottlenecks in the development process.
Then, it’s a good idea to hold daily standups to determine whether or not they are blocked. Daily standups provide an opportunity for the engineering team to discuss any challenges or obstacles they may be facing while working on the tickets. This allows for timely problem-solving and ensures that progress is not hindered. Additionally, these meetings foster collaboration and keep everyone aligned with the project’s goals and timelines.
9 Likes
Agree with @RohitKumar. I’d like to add here that to fit as much as you can into those two weeks, all of this work should be done in two-week sprints. Next, begin organizing the upcoming grooming sessions and sprint. During the grooming sessions, the team can prioritize and estimate the tickets, ensuring that the most critical tasks are addressed first. This helps in planning the sprint effectively and allocating resources accordingly. Additionally, organizing the sprint involves setting clear goals and timelines, assigning responsibilities, and ensuring that everyone is aware of their roles and tasks for the upcoming period.
A proficient product manager strives to complete tasks concurrently, staying one or two sprints ahead of their technical team. By staying ahead of the technical team, the product manager can anticipate any potential roadblocks or issues that may arise during the sprint and proactively address them. This proactive approach allows for smoother execution of tasks and helps to minimize any delays or bottlenecks in the development process. Additionally, being ahead of the team enables the product manager to provide guidance and support to their team members, ensuring that they have all the necessary resources and information to successfully complete their tasks.
8 Likes
Managing the ticket creation process involving multiple stakeholders—yourself, engineers, and designers—requires effective communication, clarity, and coordination. Here are some steps you might consider:
-
Clear Communication Channels: Establish a communication channel where everyone involved can discuss the issues, exchange information, and ask questions. This might be a shared project management tool, a messaging platform, or regular meetings.
-
Detailed Issue Description: Provide comprehensive details about the problem, including its context, impact, and any specific requirements. This forms the basis for ticket creation.
-
Collaborative Review: Before ticket creation, involve engineers and designers in a review session where you present the issue description, wireframes, and flows. Encourage questions and feedback to ensure everyone understands the requirements.
-
Template or Guidelines: Provide a standardized template or guidelines for creating tickets. This could include sections for technical details, design requirements, priority levels, etc., ensuring a consistent format across all tickets.
-
Feedback Loop: Establish a process for feedback and iteration. Engineers might need to ask clarifying questions or suggest improvements based on technical feasibility. This loop helps refine the ticket before implementation.
-
Documentation: Ensure all discussions, decisions, and changes related to ticket creation are documented. This helps in tracking progress, understanding decisions made, and resolving any future issues that might arise.
-
Regular Check-ins: Schedule regular check-ins to review the progress of ticket implementation. This allows for any adjustments or modifications if needed and ensures alignment among team members.
-
Flexibility and Adaptability: Remain flexible as sometimes issues may evolve or require adjustments. Being adaptable to changes ensures that the ticket creation process remains effective.
Remember, managing this process effectively involves not just providing information but also fostering collaboration, active participation, and a shared understanding among all stakeholders involved.
7 Likes
A ticket is a type of agreement or contract. to ensure that everyone is aware of our goals. It outlines the terms and conditions of an event or activity, including the date, time, and location. This helps in establishing a mutual understanding between the organizers and attendees, fostering a smooth and organized experience for all involved.
As long as all parties comprehend and approve of the agreement, it doesn’t really matter who writes it. The ticket serves as a legal document that protects the rights and interests of both the organizers and attendees. It can also include important information such as entry restrictions, refund policies, and any additional instructions or requirements for the event. Ultimately, a well-written ticket ensures transparency and clarity, enhancing the overall satisfaction and enjoyment of the event for everyone involved.
6 Likes
Talk about the issue, with each person contributing to its solution. The engineers and designers then decide who will do what. Most things can be done without the assistance of a designer. Since designers are able to commit code, the SWEs are not always involved. Though uncommon, it does occur. In such cases, the engineers and designers collaborate closely to ensure that the code written by the designers aligns with the overall system architecture and engineering standards. This collaborative effort allows for a seamless integration of design and functionality, resulting in a cohesive and user-friendly product. However, it is important for both engineers and designers to communicate effectively throughout the process to address any potential conflicts or challenges that may arise.
It is never front-loaded in design. When it comes to problem solutions, engineers and designers collaborate closely. The designers do more than browse. It is their duty to get user validation for the completed design. This collaboration ensures that the final product meets both the technical requirements and the user’s needs. Designers conduct user testing and gather feedback to iterate on their designs, while engineers provide technical expertise to implement these changes effectively. By working together, engineers and designers create a seamless and user-friendly solution to the problem at hand.
5 Likes
Both, based on the subject matter.
When it comes to new features, I usually outline my ideas, write them down, and then check to see whether they are acceptable.
We usually have a conversation to make any necessary corrections or changes, after which they draft a proposal and ask me whether it fulfills my wishes.
Furthermore, those are only broad guidelines rather than absolutes.
We find that it works well for them because they are well-versed in the product, while newer engineers tend to like the first option more.
4 Likes
Stories with user interfaces, happy paths, most edge cases, and business rules are all part of the epics and stories I write. Most tech debt tickets and spikes are written by developers. Developers typically write backend tickets when something needs to be broken out from the front end. I write the tickets a lot of the time, and they update them. In addition to writing tickets, I also collaborate with developers and stakeholders to gather requirements and ensure that the user stories are accurately represented. This involves constant communication and iteration to ensure that the tickets align with the project goals and priorities. As the product evolves, I continuously review and update the tickets to reflect any changes or new insights that arise during development.
3 Likes
Having an understanding with my team on clarity of work items is more important than who writes the story.
We agree on:
- Clear short verb titles
- Clear crisp Acceptance Criteria(AC), one per line
- Have timeboxed conversations followed by estimating as a team so everyone understands at least at high level what the functionality is and why this story is valuable
- There are SMEs in the team, designers, website developers, but everyone is open to participating in conversations
- As the PM/CPO, I bring ideas of what I want done in the upcoming 2 Sprints, write a few stories myself and individual SMEs help write a few
- I pre-refine stories with some initial ACs and so does the SMEs. This helps in preventing running out of time during team refinement sessions as stories do not have enough and time spent/story is too high
2 Likes
In my startup, I will write tickets for one-off small things, but for defined projects, I write a PRD, everyone discusses it, changes are made while the designer actually designs it, engineering writes a design document with my help, and when the work is ready to begin, engineering writes all the tickets.
The sole product manager here is me. I’m in love with this since it gives me so much extra time to do things other than write or rank each individual ticket. Additionally, the engineering manager oversees which tickets the engineers are working on on a daily basis; I do not. I have weekly and monthly road maps, and the engineering manager creates one for his team every week. We also meet weekly to discuss our progress and any areas where we might need to adjust our schedule. (Of course, we communicate every day, but we set aside time each week for our planning meeting.)
Every two weeks, we also have demos and stand-ups, which helps me see where people are working. Nonetheless, slack chatter is constant, with people creating looms to display their creations. Therefore, I never have to bother with the tedious labor of breaking down tasks or doing any type of micro tracking of people’s whereabouts because I always have a sense of what individuals are working on and how quickly they are working. We also have engineers who are highly focused on the product and who act independently and with ownership.
1 Like
Low technicality: I write the tickets
High technicality: I work with my tech lead to turn my requirements into tickets
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.