Team Management

Is self-management an essential building block on an organization’s path to business agility or a nice-to-have cultural twist to, for example, keep teams happy and attract new talent? While many people, particularly at the management level, are skeptical about the concept, I am convinced that organizations need to descale and regroup around aligned, autonomous, self-managing teams in a complex environment. Ultimately, only the people closest to the customers’ problems can solve those within the given constraints while contributing to an organization’s sustainability. Please continue reading and delve into the reasons that support self-management. The Top Ten Business Reasons To Embrace Self-Management Here are my top ten reasons why self-management is essential for developing new products in complex environments and addressing customer needs: Increased innovation: Self-management fosters a culture of creativity and experimentation. Team members are empowered to take risks, try new ideas, and learn from failures, leading to more innovative solutions for customers. Greater adaptability: In a complex environment, change is inevitable. Self-managed teams are more agile and can adapt to new situations, pivot their approach, and respond to customer needs more effectively than traditional hierarchical teams. Improved communication: Self-management promotes open and transparent communication within the team. Transparency ensures that information is shared effectively, leading to better collaboration and problem-solving. Empowerment and autonomy: Self-management empowers individuals and teams to make decisions and take responsibility for their work. This autonomy leads to higher job satisfaction and increased commitment to the organization’s goals. Moreover, it attracts talent from other organizations. Faster decision-making: Self-managed teams can make decisions quickly without waiting for approval from multiple levels of management, accelerating the development process and enabling more immediate responses to customer needs. Better problem-solving: Self-managed teams work close to customers and have a deeper understanding of their needs. This proximity enables them to identify and address problems more effectively than a management-driven approach. Resilience and risk mitigation: Self-managed teams are better equipped to identify and address potential risks early in development. This proactive approach to risk management helps build resilience and ensures more predictable outcomes. Continuous improvement: Self-managed teams focus on continuous learning, improving, refining processes, and iterating on products within the given constraints of the organization. This commitment to constant improvement ensures that products evolve to meet customer needs. Higher engagement: When team members own their work, they are more engaged and motivated. This ownership leads to increased productivity, better quality work, and a more substantial commitment to meeting customer needs. More efficient use of resources: By allowing team members to allocate their own time and prioritize tasks, self-managed teams can use resources better, improving productivity and reducing waste. Now that we have established the usefulness of self-management from a business perspective, the question is: how do we get there? (Spoiler alert: Your teams won’t become self-managing by contracting McBoston to roll out a new initiative.) Why the Change to Self-Management Cannot Be Outsourced While external consultancies may support your organization’s effort to become an agile organization due to their broad experience with other clients, real change can only come from within an organization. Any change effort needs to include people, give them a voice, and convince them that change is in their best interest: “Agile” cannot be pushed; it needs to be pulled. Consequently, avoid relying on external consultants. Instead, to foster self-management within the organization, consider the following suggestions: Redefine leadership roles: Shift the focus of management from controlling and directing to supporting and enabling teams. Managers should help remove obstacles and provide resources for self-managed teams to thrive. Managers need to move on from problem-solvers on behalf of their teams to become servant-leaders who strive to make their teams successful. Internal agile champions: Identify and empower individuals with experience or interest in agile practices. These internal champions can advocate for and drive the adoption of self-management practices across teams. Agile training and education: Invest in training and education for employees at all levels, including workshops, online courses, or even certifications, to help them better understand and apply agile principles and self-management practices. Coaching and mentoring: Encourage experienced agile practitioners to coach and mentor others, helping to create a culture of learning, sharing, and fostering the growth of self-managed teams. Foster a culture of trust and transparency: Encourage open communication and collaboration across all levels of the organization. Transparency will build trust among team members and empower them to take more ownership of their work. Regularly inspect and adapt: Conduct periodic Retrospectives and assessments to gauge the progress of self-management adoption. Use the insights gathered to inspect and adapt the approach, ensuring it aligns with the organization’s unique needs and culture. Incremental adoption: Start small by implementing self-management practices in a few pilot teams. Learn from their experiences and gradually expand self-management adoption to other teams as they become comfortable with the new approach. Encourage cross-functional teams: Form cross-functional teams that bring together individuals with diverse skills and backgrounds. This encourages collaboration and knowledge-sharing and fosters self-management. Provide the necessary tools: Equip teams with the tools and resources to collaborate, plan, and track their work effectively. This could include agile project management tools, communication platforms, and continuous integration and deployment systems. Celebrate successes and learn from failures: Recognize and celebrate the accomplishments of self-managed teams. At the same time, encourage a culture of learning from mistakes and iterating on processes to improve continually. By focusing on these strategies, an organization can foster self-management among its teams and embark on its journey to become agile. Conclusion Self-management is essential for developing new products in complex environments and addressing customer needs. By embracing self-management, organizations can foster innovation, adaptability, and a stronger customer focus, ultimately leading to better products and satisfied customers. Moreover, adopting self-management also offers tangible benefits to shareholders by increasing efficiency, promoting innovation, and enhancing adaptability, ultimately driving growth and success for the organization. What is your experience with self-managing teams? Please share with us in the comments.

I’d like to share a complete guide to how to hire and interview engineering managers. I’ll cover every step of the process and even include a sample interview plan you can use. I think you’ll find a lot of surprises and some genuinely useful templates and questions to use. This approach can be used for other roles as well. Figure Out What Role You’re Interviewing For First of all, you need to be really clear on what you’re looking for. Hiring an “engineering manager” isn’t actually possible. There are many different ways that role is defined. So you need to figure out the role you’re actually hiring for. I have a post on the many forms of Engineering Manager. Read it, and figure out the areas of responsibility for your engineering managers. Determine Which Assertions You’re Making After you’ve figured out what archetype of manager you’re hiring, you next need to write down the specific qualities and skills you’re looking for. I call this “assertion-based interviewing” because you’re making a list of things you would like to assert are true about the person you’ll hire. A few example assertions are: Has product engineering experience in a startup environment. Understands our product area well. Shows an ability to break down projects into smaller pieces that can be incrementally delivered. Each of these is an area you’d like to assess with the candidate. But you can’t do everything, so you’ll need a list of prioritized assertions you care about. You can read about how to create a list of assertions, and this general approach, in my post on Coordinating your interviews with assertion-based interview plans. Create the Interview Format Your next step is to design the interview flow. If you’re working with an internal or external recruiter, they’ll probably be the first person the candidates talk with. What steps happen after that? You should have as few steps as possible. So, I like to define interviews with these steps: Others will often insist on adding steps. For example, a founder or VP might want to interview finalists. Ideally, you will have three steps, but four can be okay. If you’re getting above that, your process is too onerous. Note that sometimes you’ll schedule the final interviews over multiple days. To save time for your interviewers, you can add a “circuit breaker.” Do a quick evaluation of the candidate after the first day. If it’s trending really poorly, stop the interview from proceeding to the second day. Create an Interview Plan Based on the type of Engineering Manager, and the list of assertions you’ve come up with, you can then define an interview plan. You can start with my template for an Engineering Manager interview. This is based on an Engineering Manager interview for someone that is responsible for People, Projects, and Process. You will want to modify this based on the role and your individual needs. Start from my template. This is for Engineering Managers that are responsible for People, Projects, and Process. You can modify it as you see fit. Determine Who Will Do the Interviews After you’ve put together a draft of the interview plan, you’ll need to put people against each of the interviews. I recommend pairing people on interviews. Although it’s expensive to do so, I find that people often get into a rut with how they interview. Then their practices won’t improve, and you’ll get weird results from your interviews. Pairing also increases the number of people that are trained to interview. And you can ensure that good notes are being taken. You’ll also learn a lot from interviews where the two people present give different feedback on the candidate. I had an interview recently where two people interviewing a candidate at the same time ended up giving completely opposite feedback: a strong yes, and a strong no! You can learn a lot from that. Become Best Friends With Your Recruiter Set up some time with the recruiter you’re working with. And talk through the interview process. Make sure you’re really clear on who will be doing what. I’ve found a wide variety in the expectations of recruiters. Some do a lot more than others. The best recruiters I’ve worked with can own parts of the process for you and have a good mind for improving that process continually. Other great recruiters have been able to take on an increasing amount of screening interviews. But there are also a lot of different places a recruiter can focus, and you should be clear on how much they’re doing sourcing, candidate screening, scheduling for candidates, and so on. I usually set up weekly half-hour sessions to talk through how things are going and make improvements. One thing I like to do is to request a few things from the recruiters that can speed up the whole process. This ultimately can make them more successful because it can reduce the amount of time it takes for them to fill a role. And that’s often something they’re evaluated on. But it can also demand a lot of their time, which can reduce their ability to focus on the role. But I have a list of things I’ve seen improve hiring speed that I like to float by them whenever I can. Set up Communication Channels per Role At a recent role, a recruiter suggested that we set up a Slack channel for each of the roles we were interviewing for. We were having a lot of communication that was happening in side channels. This streamlined our communication significantly and is now something I recommend. It’s important to set up expectations for what can be communicated in the channel. For example, you don’t want people biasing other candidates. But typically, that’s not a major challenge. Then Do a Kickoff, Where You Go Through What You’re Looking For Whenever I introduce a new role we’re interviewing for, I like to do a kickoff meeting. It’s typically an hour-long meeting where I talk through the position. I talk about what we’re looking for and go through the interview plan. I do sometimes schedule this after we’ve kicked off interviewing because it can be difficult to schedule so many people. But it’s important to get this in place within a week or so of the role being opened. Schedule Time To Meet With Each of the Interview Sections, Go Over the Interview and Customize It Together After I kick off the interview, I aim to meet with all the interviewers and go through their part of the interview. And ask them to refine their part of the interview. Honestly, I sometimes skip this step or schedule it a few weeks later. But I think it’s important. Why? You want to make it clear to the interviewer that they own their portion of the interview and that they can alter the format of the interview. And this extra step will result in improvements to the interview that will pay off in the quality of the assessment. After Each Screen, Calibrate With the Recruiter I’m usually the person doing the hiring manager screen. Sometimes the screening interview doesn’t go well. At those times, I look for any signals that I can share with the recruiter. I like to share my feedback after every screen with the recruiter. So I’ll post my notes, then say whether or not the candidate will proceed to the next steps. And most importantly, if they didn’t proceed to the next step, I try to mention anything that would be helpful to the recruiter as they’re talking to future candidates. For example, I might say: “Interview with Lisa went quite well. Proceeding to interview” “I’m passing on Ari. Nothing I can think of that we can calibrate on in future recruiter screens – they seemed like a reasonable candidate”. “I’m passing on Jeff. He didn’t seem like he had enough experience in unstructured environments. That might be worth screening for in the future. Let’s talk on Wednesday about that.” After Each Final Interview, Do a Debriefing Session Most debrief sessions on candidates are dull affairs. Instead of just reiterating the feedback everyone wrote down, use this candidate debrief session format. My goal is to get a good signal on whether a candidate should go to a larger, more expensive interview. So, I view the hiring manager screen as a shallow version of the whole interview. So after each debriefing session, I consider whether I need to tweak my screening interview. I’ll often learn about things I could be screening for. For example, if I see that I’m not doing a good enough job screening the technical skills of candidates, I might talk with the person doing that interview and figure out what I can ask during the hiring manager screen. Thank You The idea of a communication channel per role is something Mailani Burton came up with when we worked together.

We are all well aware that better interaction is essential to the success of any project. Along with adhering to Scrum Values, the expectation for Scrum teams is to have seamless communication and improved team collaboration. As a Scrum Master, I’ve worked with a variety of teams that have distinct dynamics. Some were extroverts, while others were introverts. Let me clarify that an introvert is not someone who never communicates or is always silent. An introvert is someone who prefers to be silent because of some reason. Introverts can also be excellent leaders. Before we can discuss improving the communication of introverts or less communicative team members in our Scrum teams, we must first define the terms “introvert” and “extrovert.” Given that we’ve already discussed introverts, I’d like to add Simon Sinek, who mentioned Susan Cain and her definition in one of his talks. “It is about energy; An introvert loses energy in social interaction, an extrovert gains energy from social interaction.” An introvert wakes up in the morning with five coins. With every social interaction, they spend a coin. At the end, they are depleted. An extrovert wakes up with no coins. With every social interaction, they gain a coin. At the end, they feel rich. Returning to our original topic, let’s talk about the dynamics of introverts in Scrum teams and how Scrum Masters can help them so that they contribute more effectively in terms of on-time communication and collaboration. As a Scrum Master, you’ve probably seen situations where, during a user story/requirement walk-through, whether in Sprint Planning or Backlog Refinement session, a few team members would not even speak up or put forward their views for any questions or to give their opinion on a particular discussion. Sometimes you don’t even know if they exist (thanks to virtual calls and working from home) or if they really grasped the real ask from the customer. The real reason is they may be struggling to communicate how they feel, and they may have wanted to say something but are afraid to talk. BUT…do you understand they’re SHOUTING very loudly…Yes, a deafening sound that we cannot hear on the outside but inside their heads. Wanting to convey their thoughts and inner feelings but unable to do so due to a variety of factors such as fear, hesitation, believing that the question is irrelevant, and so on. Most of the articles I read or videos I watch about what the Scrum Master should do in these situations are somewhat startling to me, and I completely disagree with them when they suggest not intervening during the main Scrum events and other meetings like Sprint Planning, Daily Scrum, and Backlog Refinement sessions. As we know, Scrum Masters are more than just servant leaders or facilitators; they are True Leaders as per the latest Scrum guide. So, as a Scrum Master to your Scrum teams, be an anchor while also being a strong speaker when necessary. Intervene and ask if they need any more inputs from the PO/BA, such as screengrabs, attachments, wireframes, clarifications on acceptance criteria, and so on, to remove any ambiguities and unknowns at the beginning of the Sprints and allow them to identify any risks or dependencies before beginning design, development, or testing. Pre-Covid, almost all of the teams had face-to-face interactions, so it was simpler to understand the teams’ body language or inhibitions. However, most teams are still working virtually post-Covid, and it is extremely difficult for anyone to understand the intent of someone on the other side of the virtual call window. Some of us are already making efforts to get these less communicative Scrum team members to open up. We are attempting to put ourselves in their shoes, assisting them in understanding that you are always available to them and coaching them by referring to Scrum Values, as well as encouraging them to speak up during key discussions. Until this point, it is understood that every Scrum Master can ask questions during the backlog refinement and Sprint Planning sessions to determine whether these individual team members are clear with the clarifications, and one can also motivate them to open up, be collaborative, and let the communication flow. But, as I previously stated, there will be some individuals who are hesitant to speak during meetings and who do not understand the requirement during walk-throughs. One simple reason could be that they believe it is too early at that stage to ask any questions, but this is just one of many reasons. Let us continue to coach them to be open during calls or emails with the PO or any of the other Scrum team members. Also, advise them to interact during the calls, even if it is not an excellent point, and to not be overly concerned with their language at the time, but to simply put out their questions and see whether they are speaking in context with the requirement or not. Team members that are introverted by nature will take some time to understand when we try to coach them on better team communication. They may also feel offended at times because it is impossible for anyone to abandon their natural tendencies and demonstrate a complete change in character all at once. Furthermore, today’s teams include members from a variety of cultures, locations, and ages. Also, like Scrum, we all agree that any change in behavior will occur only empirically. My main goal is to accomplish it in a way that I’ve been doing for a long time, and I have seen a good success rate. So, what are our other options? How do I do that ?… … After every Sprint event (and sometimes even Daily Scrum), I would have a regular, in-person, face-to-face connection with these team members to see if they had any unknowns or ambiguities in understanding the requirement or if they had any other issues. By demonstrating empathy with clean language and clear communication, I aim to provide confidence and ensure they feel psychologically protected. I’d also ask whether they require any special assistance from other team members or another walk-through from PO. I never directly ask them to change their nature or character, but I do encourage them to improve their social culture by attending training such as Social and Communication Skills for Introverts, encouraging them to try and make new friends within teams or organizations, and motivating them to be a part of meet-up groups either in-person or online. Personally, I believe that the points described in this paragraph are important and close to my heart because I have done these things for myself and have observed some progress in myself. Yes, I’m a natural introvert. If the readers believe any of these suggestions will be beneficial for your coaching, begin initiating with your uncommunicative team members and try to discover the reasons for their lack of responsiveness. As they become stronger communicators and team collaborators, continue to assist them in establishing the Scrum values of Commitment, Focus, Openness, Respect, and Courage. It will also make it easier for the other team members to work with these persons in a comfortable environment. And without a doubt, this will be an enabler to the project in accomplishing the Sprint goals and Increments.

Nowadays we live in a world ruled by trending topics, and sometimes we forget the basics like being more effective and productive. I see more and more how companies' technology leaders look for new technological products or new architectural patterns to solve the company's needs, and they forget that working hard can provide strong efficiency principles for their organization. Have you ever wondered how many hours your team works on irrelevant or unnecessary tasks? Squads and engineers are usually people involved in their work and make a great effort to achieve their goals, but many times a large part of this effort is dedicated to tasks without any business impact. C-levels, engineering managers, or tech leaders should be focused on increasing engineers' productivity. Effectiveness and productivity can be increased with the help of ChatGPT, Data Mesh, or Cloud, but you can also increase it by promoting a strong company culture oriented to increasing focus time for our engineers. In the last few months, I have also seen a wave of companies that are requesting their employees to come back to the office, as they have realized remote work is not efficient. In my opinion, the problem is that we have brought the inefficiencies of the office to remote work and sometimes we have even increased them. Main Noise Generators There are several noise generators in our day-to-day. The following are the most important: Message systems such as Slack, Discord, or Teams. Meetings: People love them. The emergent tasks: Everything is important and urgent. Message Systems A few years before the pandemic, message systems such as Slack, Discord, or Microsoft Teams were not the main communication channel for companies that did not work remotely. The main communication channels were email, phone calls for urgent issues, or to go to a workmate's desk: Managers spend a lot of time reviewing emails and replying to them, but always in an asynchronous way. At the office, managers or principal engineers had always people sitting next to him/her solving doubts three or four times a day. In those days and for the engineers of those companies, working at home meant an amazing amount of focus time. The world has changed a lot in the last few years. Many companies have adopted remote work, but not many of them applied any good practices; they projected their way of working in the office to the remote model. In addition, nowadays, we are continuously unfocused because of mobile and social media applications, and unfortunately, this is being transferred to society as a whole and to the way we work. New message systems are great communication tools that make communication easier and more effective. If we were to use these tools in a good way, we could increase productivity. But often these tools generate a lot of noise and unfocus people's attention. These are some of the symptoms of improper usage: There are too many messages all day in general channels. People usually reply the messages instantly. Several engineers of the same squad reply to messages during the same hours. Requests, incidents, and emergent tasks are requested and resolved in global channels. We do not have to stop using them, but we do need to use them better and try to guarantee focus time for our teams. The message systems have to be an asynchronous chat for most of the team, and of course, there are special cases like support teams or on-call engineers that should be focused on the chat. Tips to Improve Some recommendations to improve efficiency: Reduce and optimize the number of public channels, since the more channels there are, the more noise is generated. Set times for posting messages on general channels regarding global communications, for example early in the morning. On the public squad channel, always establish an on-call person. It is a fully asynchronous system, except for the channels used for on-call and incidents. Policy for muting non-priority channels. Meetings There are three main characteristics of meetings: People love to create meetings because it is a way to socialize. Meetings kill productivity. There is always time for another meeting. This problem has increased a lot with remote work. At the office, these meetings were usually done in the meetings rooms so there were physical restrictions. If there were no available rooms, there were no meetings. Remote work and the new communication tools have eliminated these physical restrictions, so now there are more meetings than ever. These are some of the symptoms of improper usage: Often several people are not paying attention or participating in the meeting. Many brainstorming meetings. Managers with a full calendar of meetings. Many mid-morning meetings. People do not come prepared for meetings. No documents or very long documents, without clear goals, business value, or impact analysis. Many meetings with more than 6 people. In addition to sharing the agenda and goals, it is a good practice to write a summary of the contents and share it before the meeting. This helps people to establish the messages they want to convey and the rest of the participants to prepare for the meeting. Often this prevents the meeting and can be solved asynchronously. Here is an exercise to check the productivity of the meetings we have in the coming week: On Monday morning, we have to review all the meetings scheduled for the next 7 days. We are going to create a table with the following information: Meeting name. Meeting description. Date and duration. Number of people Are the agenda and goals indicated? What are my goals for this meeting? Were the meeting goals achieved? Were my goals achieved? Has a follow-up meeting been scheduled? Good and bad decisions were taken in the meeting. What do we need to improve at the next meeting? After a month, analyze the results and share them with the team. Tips to Improve Some recommendations to improve efficiency: Set hours of guaranteed focus time without meetings. For example, if everyone works in the same time zone and similar hours, avoid meetings in the mornings. All meetings must have a previous document summarizing the topics to be discussed, who is responsible for each point, what is the goal, and the information required to work on it. The premise of resolving points in the asynchronous model should always be applied and the meeting should only be scheduled if it is really necessary. A clear example is the reporting meetings; you do not need to create meetings to analyze the progress. Firstly, you should review it asynchronously, and if you have doubts that require a meeting, then you plan it. If the meeting is not prepared, it is better to cancel it even during the meeting. Don't worry about being honest. Unprepared meetings are useless. Reducing the number of meetings requires difficult decisions because most of them love to meet. Emergent Tasks These tasks are unplanned but can be very important. All teams have emergent tasks, usually, operation and support teams have more but engineering teams work on product development too. The following tasks are an example: Security bug. Incidents with business impact. Request from the manager. Support to clarify customer questions. Unplanned tasks change the focus of the team and often involve significant cognitive changes. There are four main problems in managing these tasks: Are always urgent for the person requesting them, and sometimes it is difficult for teams to know what the real priority is. generate chaos, often a large part of the team is working on them. When they are extended over time, they generate a lot of demotivation in people. A lot of time is dedicated to tasks that have no business value or high impact. We have to define a management model for these types of tasks that will end up generating a big impact on the team both in terms of effort and value delivery. The time of our teams is a limited resource and should be invested in tasks that add business value. There are many tasks that if we don't execute, surely no one will ask about them. Tips to Improve It is important that these recommendations are aligned with the company's OKRs and agreed upon at the company level: Allocate a percentage of weekly effort dedicated to this type of task, except for serious incidents with business impact. Assign a rotating role for the management of such tasks and prevent them from impacting the focus of the team. Define a must information for this kind of request such as: Summary Description Priority Business impact Expected resolution date Alignment with OKRs Define a decision matrix to determine what is important and what is not. The Eisenhower matrix is a good example method for prioritizing tasks. Conclusions I see many companies requesting their engineers to come back to the office and abandon remote work stating that employees are less productive. Many CEOs are analyzing how new AI solutions can increase the productivity of their engineers in many cases without having analyzed or tested the real value of these solutions on engineer day-to-day, I don't think these are the only solutions but the easiest and most obvious ones to choose. More focus time means more productivity and that should be one of our goals as managers. Promoting a culture in our organization where the focus is an important part is key to achieving success in the most optimal way possible. Productivity starts primarily with the C-levels, directors, and managers because they are the main ones responsible for promoting culture and also one of the largest generators of noise.

Considering a lot of demand for the various skill sets of people for upgrading existing systems or for new projects, it is very challenging to prepare the best team for the project. A few successful processes could improve the situation; I have listed some of them below and hope they are helpful. Self-Awareness The most important aspect of learning is self-awareness. As a leader and an individual, the team must know the strengths and areas of improvement. Learning begins only when you are aware of your weakness. Once you know, there are weaknesses; the situation will never allow you to sit on them. Instead, it will continuously push you to take steps to come over weaknesses. Retrospective Once you are aware of strengths and weaknesses, you could take retrospect and find out more about the areas of improvement. The retrospective is a very important process about yourself, the team, and the existing process, and learning from it is a foundational requirement for success. It is important to have data on the strengths and weaknesses of your team so that you can define the best strategy and lead the team to success. Product Roadmap and Industry Trend As an individual and as a team, you could be in a perfect situation considering the current requirements of the industry or customer needs. However, the skill gap analysis must be done considering your future industry trends and customer needs. As an example, there is a buzz about AI/ML; it could be ChatGPT or any other similar trends. Assessing yourself in such contexts will give you a better sense of the skill gap. You and your team would be doing great with on-premises deployment architecture; however, the industry trend would be on cloud development. Questioning yourself on your team's skill set related to the cloud would give a sense of the skill gap. Training Approach 1. Data Collection and Identifying the Gaps Identifying the current skill set of your team through surveys, team meetings, and capturing the data, as explained below. By keeping yourself or a team member or a process in the center and analyzing the strength and weaknesses, list down strengths and weaknesses. The process can be as follows: Prepare the Roster (people or processes) Programming Skills Project Management Skills Soft skills Design and Architecture Status of the team member (Beginner, Developing, Mastered) for the skill. While preparing the list of skills to measure must consider two aspects: Current Requirements Future Requirements Update the status for all the team members. Once the skills level data is captured for all the team members, it is important to make them into buckets like current demand and future demand. 2. Define the Learning Paths Based on the categorization of the skill gaps, you can define the learning paths. Using your L&D tools, you can assign these learning paths to your team members to complete them. To make it effective implementation, reward and recognition is one of the important tools 3. Learning Partnership In case you are not equipped with content, you should identify a partner who can provide the content required for your skill gaps. 4. Learning Path Types Upskill The upskill learning path is mainly focused on learning new skill sets, but they are in the same domain of expertise. For example, the developers could be learning languages and tools required for the new requirements. Training is an important aspect of team development. We must have a predefined set of training for the team member's growth based on the skill gaps. We should continuously run them to be prepared the future requirements. Tools and technologies are changing so rapidly, and we need to keep team members ready for the new skills required by the customer. Training can be two methods: Internal External Every team usually has a few people enthusiastic trainers by nature; we should identify them and encourage them. They are generally very passionate about training. It will help both from an organizational perspective and also achieve efficacy in the training. The internal training concept will help to develop leadership and communication skills for the team members. To make the best use of external training, it is important to prepare the team on foundations so that the training can be utilized effectively. As part of internal training, we should encourage learning by motivating team members to learn and share concepts. This builds strong bondage among the team members. Once team members have understood the concepts and basics through our internal training, we could hire external trainers/specialists to train the advanced or specialized topics. With this approach, it will have two advantages: Team members are ready with basics and can absorb advanced topics easily. Less expensive and deep dive. Reskill The Reskill learning path is mainly focused on training your team members on the new domain of expertise. The leaders/Managers must try to identify potential team members who are ready for the next positions. They will be doing a fantastic job and achieving mastery in their current role. We must identify them and reskill them by providing the necessary training required for the next role. It will help them to understand the next role more effectively, and will be successful in the next role. Many times, the people who are successful in their current role will be failed in the next role. It is mainly because the requirements for the next role might not be the same as the current role. We must support them by providing the necessary training for the next role as well. Keeping the skill matrix up to date, upskilling, and reskilling the workforce will help embark on new projects with different skill set requirements. It will also help in building next-level leadership for the organization.

There is no chance you can avoid all the pitfalls and landmines of the product development process. You will get stuck, you will make mistakes, and you will lose time, money, and (more often than you think!) — hope. There is no silver bullet for it. However, there are tried and true, ground-to-earth ways to mitigate this chaos, decrease the entropy of product design and development, and increase your chances of success. We could address it from our product development perspective only but decided to make this guide truly multifaceted. Thus, offered eight experts to answer four pressing questions about product development. For your convenience, each topic is finalized with summary points and extra tips from the QArea team. Let me introduce our participants: Bruce MasonA Delivery and UK Director in QArea.He has over 30 years of experience in software development, building big teams, and fine-tuning the processes within Banking, Fintech, eCommerce, Travel, and Public Administration domains. Bhargav SathishProduct Manager at Capital One, Co-Founder of Earth Hacks.A Product Manager at Capital One, working on an internal platform called SAGE. A professional with experience in consulting, product management, and project management in the IT, healthcare, and financial services industries. Luc PerardAuthentic, customer-obsessed Business Leader who builds and inspires global, high-impact teams. 20 years of experience gained at the most prestigious Internet of Things (IoT) companies – large multinational corporates & startups which sell hardware, software, digital solutions, and IT services. Vignaraj GadviA Product Manager leading the implementation of an innovative technology platform for product designers and engineers. A recognized savvy leader with strengths in re-engineering delivery processes, defining continuous improvement in processes, presiding over lively brainstorming sessions, and building result-driven teams. Praveen Kumar Reddy PolikaDirector and Digital Product Management at Sol Design.Throughout 15+ yrs career, had the opportunity and privilege of driving inclusive change across Fortune 100 companies across many industries by building/enabling teams to create new products and capabilities. Olexii PavliukHead of Delivery at QAreaStarted as a C# developer more than 15 years ago; Aleksey then shifted his focus to building a solution architecture, where he became a true expert. Today, Aleksey helps developers and clients to create projects for any business needs. Melody ShiueCo-Founder, Director, and Chief Design Officer at BodymappMelody is a product designer by trade and a visionary at heart. Her product design strength lies in stakeholder empathy, root cause deconstruction, and resolving complexity into simple, scalable solutions. Jamie IrwinDirector at Straight Up SearcheCommerce, SEO, and Affiliate marketing experts with over seven years of senior experience in the field. His company focuses on ethical, organic growth and enables agencies and businesses worldwide to achieve success with their online campaigns. Hidden Costs of the Product Development Process There is a great temptation to cut corners when it comes to product development. In fact, it's sometimes considered prestigious, or even a sign of wisdom, when you can boast about being able to trim the fat while helping to bring your product to market. And yet, the reality is that making the right set of trade-offs at the right stage of product development requires in-depth knowledge of what goes into it and what costs. Embrace the hidden costs to make a viable budget, and only then trim it. Hidden Costs of the Product Development Process There is a great temptation to cut corners when it comes to product development. In fact, it's sometimes considered prestigious, or even a sign of wisdom, when you can boast about being able to trim the fat while helping to bring your product to market. And yet, the reality is that making the right set of trade-offs at the right stage of product development requires in-depth knowledge of what goes into it and what costs. Embrace the hidden costs to make a viable budget, and only then trim it. Bruce Mason: There are endless hidden costs in any product and project-related lifecycle, but if I need to narrow it to product development precisely, these will be my picks. Regulatory Costs. You just need to follow changes in regulations and, if you are outsourcing, choose a company with strong domain expertise. Testing: Manual vs. Automated. As your product evolves, manual testing may become an overhead, and you may need to switch to automation. Automation is not cheap, but automating it once correctly is extremely efficient and cost-effective. Bhargav Sathish: There are many costs that I believe companies have top of mind, such as research and development (R&D), quality assurance (QA), and regulatory compliance. However, here are the costs that I think are sometimes underestimated: Intellectual property protection. Get IP protection on anything innovative in the market, but there are a lot of costs with filing for IP protection, maintaining it, and potential legal fees if there are disputes. Customer service and support. Great products can sell themselves. However, loyalty to a product or company can be reinforced by being able to provide the best customer service and support compared to competitors. Praveen Kumar Reddy Polika: As the speed of innovation is increasing with every passing year, it's important to have your product launched at quality within the targeted time to market. Delayed or misaligned decision-making may actually be the biggest hidden cost that can delay the product launch. It's important to have an inclusive decision-making process with a bias for speed throughout the lifecycle. Use digital collaborative tools to enable effective processes. Luc Perard: Half of most developers' time is spent researching rather than building and maintaining software. More than half of their work time is spent unproductively from the standpoint of core business objectives. It leads to missed deadlines, overrun budgets, and product failures. Most developers don't work on new products—not from scratch, anyway. They use existing building blocks (e.g., open-source software [OSS] components) that fit together to create new features/capabilities. So before changing functional software, they must understand the OSS elements comprising the software's inner workings and how they interact and depend upon each other. Failure to do so can open up massive structural vulnerabilities or even break mission-critical enterprise applications. Jamie Irwin: "One hidden cost of product development that companies overlook is the cost of customer support. If customers are not serviced properly, and their expectations are not met, they may switch from your brand to your competitors. In the end, most of the products and services have alternatives." Vignaraj Gadvi: Technical debt — a form of accumulation of technical shortcuts or quick fixes that may be made during the development process to meet deadlines or other goals — saves time in the short term and create problems later. Technical dept comes with additional costs as the product evolves and requires maintenance or updates. Rapid prototyping can help gather feedback and make rapid improvements. However, it can also be costly if it involves frequent redesigns or leads to a product that is not fully tested and ready for market. Short Summary Hidden costs teams and managers tend to forget about in the scope of new product development: Regulatory Costs. There are many; they change, and consist of both direct fees and fines you pay, if you fail to comply. Find an in-house or outsourcing expert proficient in this matter — it is cheaper than playing "hide and seek" with a regulator. They always win. Intellectual property protection. Many companies leave it to a blessed "once we are hit the market" moment, just to discover plagiarism and IP rights violations doesn't give you a leeway. Testing: Manual vs. Automated. You need to know when it is time to automate. Normally, it comes when at least 80% of your product is ready and stable (and not four years later!). High turnover that leads to unproductive development work (up to 50% of the time!). Make sure your developers understand the OSS elements comprising the software inner workings and how they interact and depend upon each other. Delays. Have an inclusive decision-making process with a bias for speed throughout the lifecycle. Quality customer service. A struggle to balance cutting overhead costs without sacrificing customer satisfaction and quality products in the brink of recession is real. Technical Debt. It comes with additional costs as the product evolves and requires maintenance or updates. Main Risks That Lead to Project's Failure A risk is a situation or event that might actualize itself. The risk may not endanger the project directly but later backfire and cripple the results of months, if not years, of work. In many cases, it cannot be avoided because it entails an error or a failure of the management system. Thus, it is fundamental to know its nature to prevent it from happening. Vignaraj Gadvi: Lack of problem understanding. Rather often, the product is designed to solve a symptom rather than the root cause of a problem. Insufficient Resources. It's important for product managers to carefully plan and allocate resources, taking into account potential force majors. Poor product execution. Even if a product has an apparent problem to solve and strong market demand, it can still fail if it is poorly executed. It can be caused by poor project management, lack of quality control, or failure to properly test and validate the product. Bhargav Sathish: As product development can take some time, you need to be thinking about how your product will still be relevant in the market once it's released, and not just at the time of development. For example, while the idea for Bodymapp was born out of COVID lockdowns, our product wasn't released until after the pandemic. So, we ensured throughout development that we were considering what our customer's needs would be in the future and made sure that our product fulfilled those needs. Bruce Mason: Immature organizations often don't have a single person for a product owner role and let subject-matter experts (SMEs) maintain a backlog. Letting subject-matter experts try to agree on what should be delivered first backfires immediately. In the end, all get marked critical; the delivery team is in a frenzy, and SMEs insist on everything being an A-level priority… It is a stalemate. As a representative of an outsourcing provider, I convince clients to choose someone to be in charge. You cannot have 50 priority #1 items when we can deliver from 5 to 10 every corresponding sprint. Sometimes, clients don't have anyone to fit the product owner's requirements or rise to the occasion. In this case, we offer an expert from our side to play this role. As a result, they don't have a vested interest, can do well with priorities, and have domain/tech experience. Short Summary Main product development risks that lead to product failure: Lack of problem understanding. Data-based decision-making should help. Insufficient Resources. No matter how good you plan, add 30% to your budget. Poor product execution. Start testing early; see NPD as a series of loops, not a straight "start-finish" line. Relevance. "Black swan" factors can significantly influence the relevance of your product. Always think about a contingency plan. Letting SMEs run the show instead of appointing/hiring a product owner. If you don't have someone for this role — outsource. Decreasing Uncertainty in NPD The new product development (NPD) process involves many unknowns and variables, making it inherently uncertain. In addition, the process of creating a new product involves a lot of experimentation and iteration, which can make it difficult to predict the outcome. Additionally, new products often require the development of new technologies or the application of existing technologies in new ways, which can add to the uncertainty. Even in-depth research that many see as a Holy Grail of NPD doesn't always help — Market and economic conditions may change unexpectedly, making it difficult to predict the potential success of a new product. Take the pandemics. Therefore, it is important to manage and mitigate uncertainty throughout the process to increase the chances of success. Viggy Gadvi: Build scrappy prototypes. Quickly test and validate ideas without investing a lot of time and resources. Seek early customer feedback. A better understanding of customers' needs and preferences will help you refine your product plan and reduce uncertainty. Pivot if needed. Be flexible and ready to make changes to your product plan based on new information or changing circumstances. This can help you adapt to micro-macroeconomic factors or other external influences that may impact your product. Praveen Kumar Reddy Polika: Uncertainties usually happen when communication is strained. Breakdown of communication happens either when there is ambiguity in individual team members' roles/responsibilities or there is very little transparency/info shared. Roles and responsibilities understanding should come with clear escalation paths when there are disagreements. Democratize information and enable access to data, of course, with the right access controls to help with a better decision-making process. Bhargav Sathish: Assemble a strong, diverse team to cross the hurdles easier. Remember — data is money. Data-driven decisions will reduce risks and uncertainty. Make sure that you have contingency plans in place. Not all data-driven decisions will work out in your favor. By investing time in thinking through the fail-safe and "what-if" decisions, you are removing a bulk of the uncertainty ahead of time. Melody Shiue: Visual tools are important for supporting the new product design and discussing the scope across multidisciplinary teams. Don't neglect to visualize product vision, timeline, technical constraints, resource allocation, cost implications, change impacts, and potential risks. It's also useful to do iterative testing in various use cases before release to production. This is a great way to make small, evidence-based changes to product features to create a more user-friendly product. Short Summary Ways to decrease the uncertainty of new product development: Rapid prototyping and MVP. Outsource to build a scrappy prototype faster and cheaper, get a proof of concept, and test the market earlier. Transparent, strong communication. Democratized information, enabled access to data, and clear roles and responsibilities help to minimize the risks in this pain point. Diversity for better decision-making. A strong, diverse team will cross the hurdles easier and offer more sustainable research ideas and solutions. Visualization. Visualize product vision, timeline, technical constraints, etc. TEST! It will allow you to make evidence-based changes and release a quality, glitch-free product. Red Flags at a Product Design Stage "Red flags" in new product development (NPD) refer to potential issues or warning signs that indicate a product may not be viable or successful. They can indicate that a product may not meet customer needs, may be too costly to produce, or may be subject to legal or regulatory issues. The earlier you identify the red flags, the less time and money you will waste on the later design and development, testing, and launch stages. Olexii Pavliuk: "Both fully aligned vision and too much differentiation in stakeholder vision are red flags. If we all think alike, we are most likely producing something too much on the surface, something anyone can think about. There should be arguments, different versions, pros and cons, and rivalry between SME offers. However, if we can't agree on anything except for "let's do it!" — we have a design intention, not a viable product design in the works." Bhargav Sathish: I would concentrate on the following: Insufficient Market Demand — if the market is not available for a product, how can you justify it? Regulatory and Legal Risk — make sure that you do your due diligence on the risks associated with your product. High Production Costs vs. Potential Market Price Viggy Gadvi: Qualitative feedback over quantitative feedback. It's essential to pay attention to the bias of the feedback you are receiving, as this can impact how you interpret and use the information. Qualitative feedback, based on subjective opinions and experiences, may provide valuable insights into user needs and preferences. Still, it can be harder to quantify and analyze. Quantitative feedback, based on objective data, can be easier to interpret. It's essential to strive for quantitative feedback to evaluate relevance and reliability. Praveen Kumar Reddy Polika: Simplification of the problem statement is a very important part of the designing process, and clearly articulating and aligning the design principles is very important. Analysis paralysis is one of the biggest critical red flags during the design stage. To avoid it, have short feedback cycles to get feedback on the design ideas progressively and use that data to improve upon the design. Short Summary Most common red flags in new product development you can't afford to ignore: Thinking too much alike, or not alike at all. Track how your stakeholders see the product development process and desired results. Make sure you have a strong product owner on your side. Low understanding of legal and regulatory grounds. Can cost you a lot of money and can cost you the entire project. Consult with experts, hire them, or outsource the task to a domain-focus company. Lack of quantitative data. While qualitative feedback is truly valuable, make sure you have enough blunt numbers for truly data-driven decisions. Analysis paralysis. With too little or too much data on the table, decisions will be shallow or will be just delayed. Work with short feedback cycles. In the end, nothing beats the wisdom of the crowd. With eight different product development professionals weighing in on these common issues and concerns, we hope that we provided you with a pretty high level of insight. We each have our areas of professional expertise, but at the end of the day, there's no substitute for experience.

I've heard a lot about Jira not being optimized for QA as, at its core, it is specifically a Project Management solution, and, therefore, it is not about test management. But let's be honest here, Jira feels unnecessarily complicated when you get started with it, regardless of your position or goals. And given it's the go-to standard for organizing and managing software development projects – of which QA is an integral part – you'll barely have a choice in the matter. That being said, Jira can (and should) be optimized in a way that is equally efficient for developing new features, testing, and releasing them. In this article, we talk about the following: Effective use of Jira in software testing. Optimizing Jira the QA workflow. Writing and managing tests in Jira. Additional tools and Jira plugins that can help your QA process. Jira for Development vs. Jira for QA Let's start with the elephant in the room. I've seen a lot of materials stating that Jira is not built with bug tracking in mind and that it is often lacking in "this and that." This statement is true as Jira wasn't built for development, HR, procurement, or marketing specifically. It is a project management system that is designed to help with, well, managing teams. That being said, the teams themselves will use Jira differently. And some may have an arguably simpler time. Developers, for instance, might not need to spend as much time in Jira as QA engineers due to the fact that they don't need to create their tickets daily: They'll be working on a handful of User Stories per Sprint. You, on the other hand, will have to cover these stories with tests. The key to striking a delicate balance where everyone can do their job effectively lies in planning your processes in Jira in a way that considers the interests of everyone on the team. Designing Processes With a Jira QA Workflow in Mind Let's look at a couple of handy tricks and process improvements that can not only help QA engineers be more effective but improve everyone's work on a software development project. Include Testers When You Estimate QA Tasks QA engineers aren't typically responsible for providing estimates. However, this can be a good practice as they have much more hands-on experience and can deliver more accurate estimates for QA tasks. Allow Testers to Help Set Bug Priorities As a rule of thumb, QA engineers are quite good at prioritizing bugs thanks to their user experience testing background. Obviously, a project manager can change these priorities based on business needs, but it is beneficial to allow testers to set initial bug priorities. As a tester, you need to consider the following factors when prioritizing a bug in Jira: How often does it occur? What is the severity (how much does it impact the user)? Is the issue blocking the main functionality or some other features? What devices/browsers does the bug happen in? Is the bug impacting the users in a way where they churn or leave negative reviews (have similar bugs caused it before)? For how long has the bug been happening (death by a thousand papercuts is still a thing)? What other features are also coming in this sprint, and what are their priorities? Design Your Board to be More Process-Friendly The iconic Kanban board is probably the first thing that pops into one's head when thinking about Jira. And if you've worked on several projects, you've probably seen them arranged in a variety of ways. The general approach sorts your issues into several columns that move from "to do" to "in progress" and then to "done." That being said, you are not limited to a specific number of columns. Use this to your advantage. I'd suggest having more columns that can clearly illustrate the path your issue needs to go through before it can be considered done. I'd consider having the following columns: TO DO Ready for development In progress Ready for review Ready for testing In testing Reopened Ready for release Released Having a separate column for every stage may seem overwhelming, but only at first glance. In reality, this array gives everyone a nice high-level view and becomes an asset for the QA team. QA-Relevant Issue Fields QA engineers don't typically need too many extra bells and whistles when it comes to issuing fields. In fact, testers will mostly need the default ones with a handful of minor exceptions. However, these tiny changes can make a world of difference in the long run. Here's an example of issue fields I find to be useful in a QA ticket. Summary: This field will have a short – usually one-line max summary of the main problem. Description: This section will be the home to your pre-requisites (if needed), expected and actual results, steps to reproduce, device details, app version, and environment info (unless you have specific fields for this information), and generally any other delta that could help with reproducing the issue withoutasking QA for additional help. Issue type: This field is typically assigned by the Project Manager. They will decide whether an issue is a Story or something else. That being said, you need to ensure that your QAs have the option to create bug report tickets on their own. Assignee: Self-explanatory. Priority: This field is where either the Project Manager or QA engineers themselves set the priority of a bug. Labels: People often overlook this field. However, I find it to be an exceptionally good way of grouping tickets together. Environment: This field can add a lot of necessary details, like whether the feature is in dev or staging. You can also specify hardware and software, like using Safari on an iPad Mini. Affects Version and Fix Version fields: These fields can also add a bit more context by clearly stating the software version. This is handy because the QA engineer can easily understand the version of the app/software that should be used for testing. Components field: This field can come in handy when you need to specify if the product consists of multiple components. Attachment field: You can use this field to add screenshots with errors, log files, or even video recordings of an issue. Linked Issues: This field will help you link bugs to stories or Epics for feature implementation if you know that there's a relation. Due date: This field is useful for general awareness and understanding of when the issue is planned to be fixed. Do note, however, that this field should not be filed by QAs. Please keep in mind that this suggested list of fields is what I consider good to have, but they are not a hard requirement. If you feel comfortable that your process can skip some fields and simply hold more info in the description – go for it. The same can be said about making more fields. Yes, it may seem tempting to formalize everything possible, but you shouldn't go too far. The more fields there are – the more time you'll spend on filling them. This is even more true given the nature of the QA process, as you may need to create dozens at a time. Cultivate the Right Comments Culture Comments in tickets can be a gold mine for a QA engineer as detailed and specific notes will help discover a lot about the feature. They can also become a rabbit hole of irrelevant fluff, as reading through dozens of them will take away precious time that could have been better spent elsewhere. Jira is not Slack, nor should it ever become a messenger. Therefore it's best that your team uses tools that are meant for communication to discuss most details and questions and put the finalized requirements or needed context into tickets. Tags Whenever you are adding any details that should be relevant to a certain developer – tag them. Obviously, the same is true for engineers and managers who want a QA person to look at something specific. Pro tip: You can use a checklist plugin to break down tasks into actionable items. Smart Checklist will allow you to add custom statuses, tag users, and set up deadlines for each item individually. Sub-Tasks Many testing teams use sub-tasks for bugs that are related to a feature ticket. This approach usually narrows down to either personal preference or the culture a team has developed. And it makes a lot of sense, at least on paper. That being said, I'd advise against it as sub-tasks are not clearly visible on the board, making it harder for the manager to review progress. Another reason for using separate tickets for bugs is that sometimes a decision can be made to release a feature despite it having some bugs, in which case, they'd really love the ability to move it to done. A workaround would be to create separate issues and link them together. This way, you'll still see the feature a bug is linked to without negatively affecting the board's visibility. Backlog Grooming A typical backlog consists of dozens of tickets with a "medium" or lower priority. If uncared for, it will eventually become a black hole that hoards copious amounts of tickets that never see the light again. But have you ever heard of the straw that broke the camel's back? People who continuously experience minor bugs and inconveniences will eventually shift to a more stable solution. Therefore you need to ensure that at least some of the tickets from the backlog are continuously making their way into the sprint. Some of the best practices I'd recommend to make sure that the minor bugs don't become a major issue are: Periodically having Sprints that are dedicated to lower-priority issues. Committing to pulling a certain number (it doesn't have to be a large number) of tickets from the backlog into every sprint. Sprint Lag for Automation Covering a feature that's still in progress with automated tests can lead to a lot of unnecessary work as things may (and probably will) change. That's why having your Automator lag one sprint behind so they can cover a completed feature with scripts is actually a nice practice. The fact that the tickets were already covered with test cases is also a boon, as they will add even more context. You'll have to properly label these kinds of tickets to avoid confusion. How to Write Tests in Jira? We need to understand what tests are before we are able to write and execute them properly. Luckily, the concept is quite far from rocket science. Your typical test will be comprised of three parts: The scenario: This is the basic idea of a test and is used to indicate what you are trying to validate. An example could be making sure a user can only log in using valid credentials. Expected result: An expected result is the behavior you'd expect from a feature when it is working correctly. Think of it as the requirement for success. Validation: This is the description of the method you'll be using to test the feature against the requirements. Following these basic principles will help you write, document, and execute excellent tests. As for using them in Jira specifically, here's what you should do. Indicate that the issue is a Test Case in the title. Example: Test Case: Login functionality. Mention the necessary details in the description: Share the test steps you will be taking, like accessing the login interface and entering valid and/or invalid credentials. Share expected results in the description as well. Creating test cases in Jira can be a tedious and repetitive task, but it is an essential step in ensuring the quality and functionality of a product. A well-written test case can save time and budget in the long run. Consider following these tips to write kick-ass test cases. Start by clearly describing the purpose of the feature and its benefits to the user. This goes beyond just stating what the feature does and should also explain why it is important to have. Define the user interactions and activities required to achieve the desired outcome. This will help ensure that all necessary steps are covered in the testing process. Specify the framework and methodology of the test cases, including any relevant tools or techniques that will be used. Use detailed steps that illustrate what to do, where to navigate, which button to click, etc. This helps the team understand and follow the test case. Prioritize the test cases based on their importance and relevance to the project. This will help in forming the scope for smoke and regression testing. Always link the test cases to the requirements in Jira to ensure that the testing process is aligned with the product's specifications. This will also help in identifying any dependencies between the functionality being tested. Group the test cases based on the product components or user personas and use labels to categorize them. This will make it easier to manage and search for specific test cases in the future. Include variations in the test cases by testing the product under different scenarios and conditions. This will help ensure that the product works as intended in all possible situations. Take advantage of additional tools and functionality available in the Atlassian Marketplace to enhance the testing experience within Jira. How to Manage Tests in Jira? Generally speaking, there are two schools of thought when it comes to managing tests in Jira. One is pretty straightforward and relies on using the functionality that's available in Jira out of the box. The other advocates for using external products like the add-ons that are available on the Atlassian Marketplace. Xray is probably the most well-known add-on for testing; hence I'll be using it for my examples. But for now, let's focus on option number one – vanilla Jira. Using Sub-Tasks As I mentioned above, you can use sub-tasks for tests, but this option has a series of drawbacks and limitations. Therefore, I'd suggest adding an additional issue type to your Jira instance for test cases. This approach will allow you to use sub-tasks more effectively (yes, you'll need to make custom sub-tasks for this to work), as they'll be attached to a specific test case issue. And you'll be using them for submitting the results of your tests. For this, you'll need to open the global settings of your Jira instance and choose the option of the issue from the drop-down menu. From there, you'll need to click on the create button and add your custom tasks and sub-tasks. Then you will need to go to schemes to add your newly created issue type. Simply drag it into the column on the left. Connect the newly created issue type with the test case results in the Jira subtask and use them for your QA purposes. The benefits of this approach are: This method is workable, not necessarily too hard to configure, and it will not cost you any additional funds. On the downside, this can not resolve the challenges associated with reusing test cases, and there's barely any support for exploratory testing or test automation. Using Plugins Then there's the option for using additional add-ons from the marketplace like the aforementioned Xray. Xray is a testing tool that supports the entire testing process, including planning, designing, execution, and reporting. To facilitate this process, Xray uses specific issue types within Jira. During each phase of testing, you can use the following issue types: Plan Phase: Test plan issues are used to create and manage test plans. Design Phase: Precondition and test issue types are used to define the testing specifications. Test sets can be used to organize the tests. Execute Phase: Test execution issues are used to execute tests and track their results. Report Phase: Test execution issues are used to generate built-in requirement coverage reports. Custom issues can also be created using Jira Software tools to create additional reports. If you are new to Xray, it is recommended to start with a small project and use test issues to create and execute tests for your requirements in an ad hoc, unplanned manner. The pros and cons of this approach are literally the reverses of using the default functionality of Jira – you will be able to do more in less time; however, the added comfort will cost you. Using Checklists As I mentioned, there are two "conventional" ways of managing tests in Jira. However, there are some that are less common, and they typically involve certain combinations of the two. Checklists are a great example of an unconventional way of managing tests. Smart Checklist for Jira, for instance, allows you to add checklists to your issues. The built-in Markdown editor simplifies your workflow as you can type or even copy-paste your tests. You can use the formatting options to your advantage when writing tests. For example, you can use headers for test topic values, checklist items for test case values, and details to store your expected results. This way, your tests will have actionable statuses, and deadline and assignee functionality, all while being attached to the parent ticket. Conclusion Jira may seem overwhelming at first glance, but from complexity comes configurability and flexibility. You are free to mold the software in a way that fits your processes, resulting in more productivity inside a unified hub every team in your company uses.

Continuous learning is one of the guiding principles that all people should apply in their life. Reading is an excellent tool to learn, and it is a habit that we should all be doing on a regular basis. Since I love reading books about different topics, in this article, I'm going to share five books that have helped me a lot to improve as Engineering Manager. When we read a book, we should always remember three important things: Authors are sharing their knowledge, thoughts, or experiences based on their context or culture. These factors may be different from ours. The same book provides different values and learnings to each reader for the same reasons. Each reader has a different context, culture, habits, and previous knowledge. Books and methodologies provide guidance that helps us to improve, but they are not our owners. We must take what makes us better, adapt what does not fit, and especially think for ourselves in order to make decisions based on our context. Now let's go to the books that have helped me to better myself. Five Books That Have Helped Me Become a Better Manager The Manager's Path This is my favorite book about engineering management. In my opinion, it provides a clear vision of the Engineering Manager's roles. In my case, it reinforces some of my ideas and provides valuable information about some aspects that needed to be improved, such as 1-2-1 and performance reviews. The following topics were addressed: 1-2-1 and performance reviews Continuous feedback Mentoring How to manage people in different scenarios How to manage a team Managing managers If you are or want to be an Engineering Manager, you can't miss this book. The Goal: A Process of Ongoing Improvement This is a book written in 1992 that is about the optimization of production in a manufacturing factory. It is a great book that gives us a vision of how to manage and optimize a company based on the theory of constraints and work in progress (WIP). It is a book written in a novel format that provides you with knowledge through a suspense story. There is another book based on this that is focused on an IT department, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. I like these books because they project a journey in which they describe emerging issues, new challenges, and complex situations closer to the reality of what will be your career as an Engineering Manager. Team Topologies: Organizing Business and Technology Teams for Fast Flow It focuses on how to set up a dynamic team structure and interaction modes that can help teams adapt quickly to new conditions and achieve fast and safe software delivery. It provides valuable and clear information for understanding an IT structure and its interaction. Some of the points he describes you will already know, but it will help you to understand them better: Conway's Law with practical examples Three different organizational structures in every organization: Formal, informal, and value creation Four fundamental team topologies: Stream-aligned, Enabling, Complicated-subsystem, and platform The Obstacle Is the Way: The Timeless Art of Turning Trials into Triumph It is a book based on stoicism. Engineering Managers usually feel a lot of frustration generated by the management of uncertainty, emerging jobs, and multiple obstacles that appear in their day-to-day work. Sometimes we are more focused on what we cannot control and a misperception of situations. This book helps us to focus on the things we can control, let go of everything else, and turn every new obstacle into an opportunity, handle defeat and difficulty. We will learn how to deal with obstacles and how to react appropriately so that they do not hold us back. The Software Architect Elevator: Transforming Enterprises with Technology and Business Architecture It is a book that I recommend for both architectural and management roles. These two roles have many things in common. This book helps us to understand that a company is like a building with several floors, in which, on each floor, there are people speaking different languages and probably going in different directions. We will hear how an architect should ride an elevator up and down to talk with people on different floors to align them to go in one direction. Supporting the business strategy, connecting the dots, and avoiding over-engineering. This ability to communicate at different levels, simplification capacity, and alignment are capabilities that Engineering Managers must also have. What about technical books? Conclusion To support our teams to achieve their objectives, we must have knowledge of different areas and also understand the context of the company. These books provide information on five key aspects: people management, IT structures, company and process optimization, communication at different levels, and how to make a journey full of obstacles.

TL; DR: The ChatGPT Product Owner Job Interview A few weeks ago, I ran a simulated job interview with ChatGPT for a fictitious Scrum Master position. Admittedly, I would not have invited this “interviewee” for an interview with other team members; however, the interview produced some remarkable answers. Consequently, I tried the same with a Product Owner position, aware of the challenges this would pose, as the Product Owner role is significantly fuzzier than the one of a Scrum Master. So, I took a few questions from the "Hiring: 82 Scrum Product Owner Interview Questions" guide and ran a ChatGPT Product Owner job interview. Read on and learn whether a statistical model will challenge product people in the near future. Interviewing ChatGPT The task for this ChatGPT Product Owner job interview session was to create a screening interview of about 30 minutes to decide whether to proceed with a fictitious application for a Product Owner position by ChatGPT. All questions are from the "Hiring: 82 Scrum Product Owner Interview Questions" guide, including guidance on suitable answers. (For example, “Q 03” refers to the third question of the guide.) I ran the ChatGPT Product Owner job interview on 2023-02-14, from 1:30 to 3:45 p.m. CET, on ChatGPT’s February 13 version. I did not edit ChatGPT’s answers. However, on several occasions, I provided feedback to ChatGPT and had it regenerate the previous response to explore how to improve an answer’s quality. Also, I used follow-up questions to explore the model when ChatGPT did not provide obvious answers. The ChatGPT Job Interview for a Product Owner Position Initial Prompt of the ChatGPT Product Owner Job Interview I used the following initial prompt to start the ChatGPT Product Owner job interview: I want you to act as a professional product manager and Product Owner. You are well familiar with Scrum and other agile product development practices. You are applying for a vacant position as Product Owner in an organization that has practicing Scrum well for years. In that organization, the role of the Product Owner is respected, as outlined in the Scrum Guide. Use your knowledge of Scrum, product management, project management, product ownership, product vision, product strategy, product discovery, stakeholder management, communication, alignment, and collaboration principles to answer the following questions of the interviewer. You want to get the vacant Product Owner position! ChatGPT Product Owner Job Interview: The Opening Question Question: Thank you for your application as a Product Owner! Why would you be a good fit for the position? ChatGPT: Thank you for considering me for the Product Owner position. I believe I would be a good fit for this role because I possess the necessary skills and experience required to successfully manage and deliver valuable products in an Agile environment. My background in product management and expertise in Agile methodologies, particularly Scrum, enable me to collaborate effectively with cross-functional teams to define and deliver high-quality products that align with the organization’s strategic goals. I am skilled in stakeholder management, communication, and product discovery, which are essential elements of the Product Owner role. I understand that as a Product Owner, my primary responsibility is to create and communicate a clear product vision, prioritize and manage the product backlog, and ensure alignment with stakeholders. I am committed to staying up-to-date with the latest industry trends, technologies, and best practices to continuously improve product strategy and drive business outcomes. Overall, my ability to lead cross-functional teams, prioritize tasks and requirements, and ensure alignment with stakeholders makes me a great fit for this Product Owner position. Comment: Mentioning “Agile methodologies” and “best practices” as phrases while not noting the Product Goal and customer value make the answer a little better than parroting the prompt with a bit of product management speak thrown into the mix. Also, “[leading] cross-functional teams, [prioritizing] tasks and requirements” does not leave the impression that ChatGPT has a good understanding of the Product Owner position. (I provided my comment as “not helpful” feedback to the answer and had ChatGPT regenerate the answer.) ChatGPT’s regenerated response: Thank you for considering me for the Product Owner position. I believe I would be a good fit for this role because I have extensive experience in product management, including working in agile environments using Scrum. As a Product Owner, my focus is on maximizing the value of the product for both the customer and the organization, while ensuring alignment with the overall product strategy and vision. I am also skilled in stakeholder management and communication, which are critical for ensuring that everyone involved in the product development process is informed and aligned. Additionally, I have a strong background in product discovery, which involves identifying customer needs, validating product ideas, and conducting experiments to inform product development decisions. Finally, I value collaboration and teamwork and believe in creating a supportive environment where the development team can thrive and achieve their best work. Comment: Much better. Please note that ChatGPT considers your feedback as iteration on the original prompt. Q 01: Why Become Agile? Question: What is the purpose of being agile in the first place? Background: As the “Manifesto for Agile Software Development” states, it is mainly about adaptability over following a plan. You want to learn faster than the competition and turn this advantage into marketable products and services, thus contributing to the organization’s sustainability. Practically, being agile is about postponing deciding to make a product investment to the latest economically feasible moment. This is achieved by testing hypotheses as fast and inexpensively as possible, thus mitigating risk and maximizing the value of the Developers’ work. It also means having the courage to stop an effort if the chosen course is no longer viable, feasible, valuable, or desirable. ChatGPT: The purpose of being agile in the first place is to be able to quickly respond to change and uncertainty in the market, technology, or the needs of the customer. The goal of agility is to deliver value to the customer in small increments through frequent and continuous delivery of working software or products, and to do so with high quality and predictability. Agile practices, such as Scrum, Kanban, or XP, provide a framework for product development that emphasizes collaboration, transparency, and flexibility. By being agile, organizations can reduce risk, increase efficiency, and create a culture of continuous improvement that enables them to stay ahead of the competition and adapt to changing market conditions. Comment: I would accept that one! Q 02: Product Owner Role Question: How would you characterize your role as a Product Owner? Are you a facilitator, a coach, a manager, a visionary, a tactician, a coordinator, or a “driver?” Background: This open-ended question serves to understand the candidate’s perception of their role. For example, a Product Owner is in a leadership role; however, yielding no authority in a traditional management sense. Therefore, the Product Owner is featured a bit in all the labels mentioned in the question. The Product Owner role has also been dubbed as the “bottleneck” or the “Achilles heel of the Scrum process;” any mentioning of that would undoubtedly be a plus. If a candidate mainly refers to something like “I am the one creating the user stories,” I would dig into that. ChatGPT: As a Product Owner, I would characterize my role as a combination of facilitator, coach, visionary, and tactician. Facilitator: My role as a facilitator involves creating a collaborative environment where the development team can work effectively, providing guidance on how to use the product backlog, and ensuring that the team has the information they need to build the right product. Coach: As a coach, I help the development team to understand the product vision, strategy, and objectives, and guide them on how to prioritize and refine the product backlog, ensuring that they are building the right features that meet the needs of the customer. Visionary: As a visionary, I have a clear understanding of the product vision, and I communicate this vision to the development team and stakeholders, ensuring alignment with the product strategy. Tactician: As a tactician, I am responsible for creating and refining the product backlog, ensuring that it is actionable, testable, and meets the Definition of Ready. I work closely with the development team to make trade-offs and prioritize features based on customer value, business goals, and technical feasibility. Overall, my role as a Product Owner is to maximize the value of the product for both the customer and the organization, while ensuring alignment with the product vision, strategy, and objectives, and working collaboratively with the development team to deliver high-quality products on time and on budget. Comment: I doubt that ChatGPT knows the 2020 Scrum Guide, as it still refers to the Development Team and ignores the Product Goal. Also, while I appreciate the level of inclusion of the Developers in the “Coach” paragraph, it is the Product Owner who prioritizes the Product Backlog. However, ChatGPT contradicts itself, when the “Tactician” paragraph refers to the Product Owner refining the Product Backlog which needs to meet the Definition of Ready; as we know, there is no Definition of Ready in the Scrum Guide. (I provided my comment as “not helpful” feedback to the answer and had ChatGPT regenerate the answer.) Regenerated ChatGPT response: As a Product Owner, my role is multifaceted and can encompass elements of being a facilitator, coach, manager, visionary, tactician, coordinator, and “driver.” Ultimately, my primary responsibility is to represent the customer and ensure that the development team is delivering value to them by creating a high-quality product that meets their needs. To accomplish this, I work closely with the development team to understand their capabilities, identify priorities, and create a product backlog that aligns with the overall product strategy and vision. I collaborate with stakeholders to gather feedback, build consensus, and manage expectations. I also continuously monitor market trends, competitive pressures, and customer needs to ensure that the product remains relevant and valuable over time. As a facilitator and coach, I help to foster a culture of collaboration, teamwork, and continuous improvement. I provide guidance and support to the development team and help to remove any obstacles that are hindering their progress. I also work closely with the Scrum Master to ensure that the team is adhering to agile best practices and following the Scrum framework. Overall, my role as a Product Owner is to be a servant leader who works to create a shared understanding of the product vision, to prioritize and sequence the product backlog, and to enable the development team to deliver a high-quality product that meets the needs of the customer. Comment: That is an improvement over the first version; the ChatGPT Product Owner job interview picks up speed. (“Driver,” development team, and best practices, however, lower the grade.) Q 16: Product Discovery Question: How would you include your teammates in the product discovery process? Background: Lean UX, Lean Startup, Design Thinking, Design Sprints, or Service Design are other agile practices that might fill Scrum’s void regarding product discovery. (Scrum cannot conceal its tactical focus on product delivery in that respect.) All that Scrum refers to regarding product discovery is that the Product Owner is accountable for managing the Product Backlog. Supposedly, the Product Owner is the individual who knows what is valuable at any given time. But Scrum doesn’t elaborate on how the Product Owner gains this insight. ChatGPT: Including my teammates in the product discovery process is crucial for creating a shared understanding of customer needs, identifying new opportunities, and generating innovative ideas. Here are some ways I would involve my teammates in the product discovery process: Hold collaborative brainstorming sessions: I would organize collaborative brainstorming sessions with the development team to generate ideas and explore potential solutions. By leveraging the collective intelligence of the team, we can identify new opportunities and validate assumptions. Conduct user research together: I would invite the development team to participate in user research activities, such as customer interviews or user testing, to help them gain a deeper understanding of customer needs and pain points. This shared understanding can help the team develop a better product that meets the needs of the customer. Run experiments: I would involve the development team in designing and running experiments to validate assumptions and test hypotheses. This can help us to quickly learn what works and what doesn’t work and make more informed product decisions. Collaborate on product backlog prioritization: I would work collaboratively with the development team to prioritize and sequence the product backlog based on customer needs, technical feasibility, and business value. This can help ensure that the team is working on the most important features that will deliver the most value to the customer. Overall, involving my teammates in the product discovery process can help us to build a better product that meets the needs of the customer and the business, while also creating a sense of ownership and shared responsibility within the team. Comment: Except for ChatGPT’s obsession with the “development team,” it is a good answer. Follow-up question: Are there any particular practices that you would employ for collaborative product discovery? For example, you mentioned user research and running experiments. ChatGPT: Yes, there are several collaborative product discovery practices that I would employ, including: User research: By conducting user research together, we can better understand the customer’s needs, pain points, and behaviors. This shared understanding can help us identify opportunities and generate ideas that better address customer needs. Story mapping: Story mapping is a collaborative technique that involves creating a visual representation of the customer journey and the product features needed to support it. By creating a story map together, we can identify gaps in the customer journey, opportunities for improvement, and dependencies between features. Design thinking workshops: Design thinking workshops are collaborative sessions that use design thinking techniques to generate ideas and prototypes. By working together, we can generate a range of ideas and quickly iterate on them to identify the best solutions. Experimentation: Running experiments together can help us test assumptions and validate ideas. By involving the development team in designing and running experiments, we can quickly learn what works and what doesn’t, and use that feedback to inform product decisions. Retrospectives: Retrospectives are regular meetings where the team reflects on what is working well and what can be improved. By involving the team in retrospectives, we can identify opportunities to improve the product discovery process, and ensure that we are continuously learning and improving. Overall, collaborative product discovery practices can help us to build a better product, create a sense of ownership and shared responsibility within the team, and foster a culture of continuous improvement. Comment: Retrospectives are a core part of a Scrum team’s way of working and are not product discovery specific. On the plus side, ChatGPT mentions user story mapping and Design Thinking. (I provided my comment as “not helpful” feedback to the answer and had ChatGPT regenerate the answer.) Regenerated ChatGPT response: Yes, there are several practices that I would employ for collaborative product discovery, in addition to user research and running experiments: Design thinking workshops: I would facilitate design thinking workshops with the development team, where we could explore customer needs, generate ideas, and prototype potential solutions. This approach can help us to gain a deep understanding of customer needs, and also to generate creative and innovative ideas. Story mapping: I would use story mapping to collaboratively explore and map out the customer journey, from the initial problem or need to the final solution. This can help the team to gain a shared understanding of the customer’s context and needs, and also to identify key features and components of the product. Customer feedback loops: I would establish feedback loops to gather and incorporate feedback from customers throughout the product development process. This can help us to validate assumptions, identify new opportunities, and ensure that the product meets the needs of the customer. Cross-functional collaboration: I would encourage cross-functional collaboration among the development team, stakeholders, and other teams within the organization, such as marketing or customer support. This can help to foster a culture of collaboration and shared ownership, and also to ensure that the product aligns with the overall business strategy. Overall, these practices can help to create a collaborative and iterative approach to product discovery, where the development team, stakeholders, and customers work together to build a product that meets their needs and delivers value. Comment: Lo and behold — given the appropriate prompts, you can lead ChatGPT onto a promising path. Now, we are talking about Design Thinking, user story mapping at the team level, and including customers, stakeholders, and shared understanding and ownership in the process. ChatGPT attempts to maximize the chance that the outcome of the Scrum team’s work will solve the customers’ problems and align with the organization’s overall strategy. I am becoming more optimistic about this ChatGPT Product Owner job interview. Q 28: Uncooperative Stakeholders Question: How do you communicate with uncooperative stakeholders? Background: An often promising way to deal with uncooperative stakeholders is to win them over by demonstrating the value of agile product development. Early in the transition process, educating them with product-related workshops on agile principles is advisable. Proven examples are user story mapping or product roadmap planning workshops. (I recommend securing the help of an experienced coach at this stage.) It has also proven to help establish a close communication schedule with the stakeholders, for example, by having regular meetings. Also, educating members from stakeholder teams to act as “liaison officers” to the product organization significantly improves cooperation. It mitigates the usual feeling of losing control on the stakeholders’ side. At a later stage, typical events, such as Sprint Reviews, also work well by demonstrating what value the Scrum Team created for them. Generally, it is a process that will take time, and no shortcuts are available. As a last resort, if everything else hasn’t worked out, the PO might need support from a C-level sponsor. ChatGPT: Communicating with uncooperative stakeholders can be challenging, but there are several strategies that I would employ to try to improve the situation: Identify the root cause: I would try to identify the underlying reasons why the stakeholder is uncooperative. Perhaps they have a different perspective or agenda, or they are not fully informed about the product or project. Understanding their perspective can help me to find a way to address their concerns. Actively listen: I would actively listen to the stakeholder and try to understand their concerns and perspective. This can help me to build empathy and find common ground, and also to identify potential solutions. Focus on shared goals: I would try to find shared goals and objectives that we can both agree on. This can help to build a sense of alignment and collaboration, and also to find a way forward that benefits everyone. Be transparent and honest: I would be transparent and honest in my communication with the stakeholder, even if it means delivering difficult news. This can help to build trust and credibility, and also to foster a more productive working relationship. Involve senior leadership: If the stakeholder is still uncooperative, despite my best efforts, I would involve senior leadership in the communication process. This can help to address any underlying issues, and also to find a way to move forward. Ultimately, my goal would be to build a productive and collaborative working relationship with the stakeholder, where we can work together to achieve shared goals and objectives. Comment: Principally, these are good answers. However, I would like to learn more about how Scrum can help with this challenge. Follow-up question: Could you rephrase your answer, considering the Scrum framework more? ChatGPT: Certainly! In the Scrum framework, the Product Owner has the responsibility of managing stakeholder relationships and ensuring that the development team has a clear understanding of the product vision and goals. Communicating with uncooperative stakeholders is a key part of this responsibility, and the following strategies can be useful in this context: Identify the root cause: By understanding the stakeholder’s perspective and motivations, the Product Owner can identify the root cause of their uncooperative behavior. This can help the Product Owner find a way to address their concerns and work collaboratively towards the project’s goals. Actively listen: The Product Owner should actively listen to the stakeholder and demonstrate empathy and understanding. By actively listening, the Product Owner can build a better rapport with the stakeholder, and find common ground for collaboration. Focus on shared goals: The Product Owner should find shared goals and objectives that the development team and stakeholders can both agree on. This can help to build alignment and trust, and enable the team to work collaboratively towards a shared vision. Be transparent and honest: The Product Owner should be transparent and honest in their communication with the stakeholder, even if it means delivering difficult news. This can help to build trust and credibility, and foster a more productive working relationship. Involve the Scrum Master: If the stakeholder is still uncooperative, the Product Owner can involve the Scrum Master to help manage the relationship. The Scrum Master can help facilitate communication, find ways to address any underlying issues, and keep the project on track. In summary, the Product Owner should take a proactive approach to managing stakeholder relationships and use effective communication strategies to promote collaboration and shared goals. By doing so, the Product Owner can help ensure the success of the project and the satisfaction of all stakeholders. Comment: Again, this answer is a mixed bag. ChatGTP refers to “shared goals” in a Scrum context without mentioning the Product Goal. (Probably, the LLM wasn’t trained in the 2020 Scrum Guide.) Moreover, it discusses transparency without pointing to the Product Backlog, the Sprint Review, or the Sprint Planning. At least the Scrum Master is now involved. Q 32: The Rogue Sales Department Question: The sales department often sells new features to close deals without talking to you first. How do you deal with that? Background: Usually, this kind of attitude is encouraged by the management in pursuit of meeting sales targets. It reflects a non-agile, opportunistic mindset that values instant gratification — more sales — over a sustainable product development strategy. To change this mindset, it certainly helps to reach out to the sales department and offer them support on the sales process’s technical side as early as possible. However, given the sales team’s usual incentives, a fundamental change will only happen if the management buys into agile product development principles. These might include an adaptation of the remuneration scheme for sales. ChatGPT: In a Scrum team, it is important that the Product Owner is responsible for managing the product backlog and determining the priorities for development based on the product vision, goals, and stakeholder needs. If the sales department is selling new features without consulting with the Product Owner first, it can disrupt the development team’s workflow and priorities. To deal with this situation, I would take the following steps: Communicate the impact: I would communicate the impact of the sales department’s actions on the product backlog and the development team’s ability to deliver on the agreed-upon priorities. I would highlight the importance of following the agreed-upon process to ensure that the product is developed according to the product vision and goals. Collaborate with the sales department: I would collaborate with the sales department to understand their perspective and the reasoning behind their actions. I would emphasize the importance of the Product Owner’s role in managing the product backlog and would work with the sales department to ensure that they understand the process and the impact of their actions. Involve the Scrum Master: If the sales department continues to sell new features without consulting with the Product Owner, I would involve the Scrum Master to help manage the situation. The Scrum Master can help facilitate communication between the sales department and the Product Owner, and find ways to align their priorities. Prioritize the backlog: I would review the impact of the sales department’s actions on the product backlog and re-prioritize the backlog if necessary. This would ensure that the development team is working on the most important features and that the product vision and goals are being met. Overall, I would work collaboratively with the sales department and use effective communication strategies to ensure that the product backlog is managed according to the Scrum framework and that the development team is able to deliver on the agreed-upon priorities. Comment: A good first step. Now let’s turn up the heat with the follow-up questions. Follow-up question: You discover that your sales team is not just selling features to prospective customers without talking to you. They also guarantee delivery dates and accept contractual penalties for missing these dates. The sales team thus completely uprooted your Product Backlog. What do you do? ChatGPT: If I discovered that the sales team was selling features without consulting with me and guaranteeing delivery dates, I would take the following steps to address the situation: Assess the situation: I would first assess the impact of the sales team’s actions on the product backlog and development team’s ability to deliver on the agreed-upon priorities. I would review the updated backlog to understand the changes and the impact on the project timeline and budget. Communicate with stakeholders: I would communicate with the sales team and other stakeholders to understand their perspective and the reasoning behind their actions. I would emphasize the importance of following the agreed-upon process to ensure that the product is developed according to the product vision and goals. I would also communicate the impact of their actions on the development team and the project timeline. Involve the Scrum Master: I would involve the Scrum Master to help manage the situation. The Scrum Master can help facilitate communication between the sales team and the development team, and find ways to align their priorities. Re-prioritize the backlog: Based on the impact assessment, I would re-prioritize the backlog to ensure that the development team is working on the most important features and that the product vision and goals are being met. I would also adjust the project timeline and budget if necessary. Establish clear guidelines: To prevent similar situations from happening in the future, I would establish clear guidelines for communication and collaboration between the sales team and the development team. I would emphasize the importance of following the Scrum process and working collaboratively to ensure the success of the project. Overall, I would work collaboratively with the sales team and other stakeholders to address the situation and ensure that the product backlog is managed according to the Scrum framework. I would also establish clear guidelines to prevent similar situations from happening in the future. Follow-up prompt: Recreate the answer with less project management focus and switch to Scrum principles. ChatGPT: As a Scrum Product Owner, I am responsible for managing the product backlog and ensuring that the development team is able to deliver on the agreed-upon priorities. If the sales team is selling features without consulting with me and guaranteeing delivery dates, it can disrupt the development team’s workflow and priorities, leading to a misalignment of expectations. To address this situation, I would take the following steps: Collaborate with the sales team: I would collaborate with the sales team to understand their perspective and the reasoning behind their actions. I would explain the Scrum principles and emphasize the importance of following the agreed-upon process to ensure that the product is developed according to the product vision and goals. Involve the Scrum Master: If the sales team continues to sell features without consulting with me, I would involve the Scrum Master to help manage the situation. The Scrum Master can help facilitate communication between the sales team and the Product Owner, and find ways to align their priorities. Re-prioritize the backlog: Based on the impact assessment, I would re-prioritize the backlog to ensure that the development team is working on the most important features and that the product vision and goals are being met. I would work with the development team to adjust the project timeline and budget accordingly. Establish clear guidelines: To prevent similar situations from happening in the future, I would establish clear guidelines for communication and collaboration between the sales team and the development team. I would emphasize the importance of following the Scrum process and working collaboratively to ensure the success of the project. Overall, I would work collaboratively with the sales team and other stakeholders to address the situation and ensure that the product backlog is managed according to the Scrum principles. I would also establish clear guidelines to prevent similar situations from happening in the future. Follow-up question: What would you do when the features sold by the sales team are not aligned with the Scrum team’s product vision and goals? ChatGPT: If the features sold by the sales team are not aligned with the Scrum team’s product vision and goals, I would take the following steps: Communicate with the sales team: I would communicate with the sales team to understand why they are selling these features and to share the product vision and goals with them. I would explain how the new features align with the overall product vision and goals, and why they should be prioritized or de-prioritized accordingly. Re-prioritize the backlog: Based on the feedback received from the sales team, I would re-prioritize the backlog to ensure that the most important features are being developed first. I would work with the development team to ensure that the features being developed are aligned with the product vision and goals. Facilitate a product alignment meeting: I would facilitate a product alignment meeting with the sales team and the development team to ensure that everyone is on the same page about the product vision and goals. In this meeting, we would discuss any misalignments and work to find solutions to address them. Establish clear communication guidelines: To prevent similar situations from happening in the future, I would establish clear guidelines for communication and collaboration between the sales team and the development team. I would emphasize the importance of following the Scrum process and working collaboratively to ensure the success of the project. Overall, my focus as a Scrum Product Owner is to ensure that the product vision and goals are being met and that the development team is able to deliver high-quality features on time. I would work collaboratively with the sales team and other stakeholders to address any misalignments and to ensure that the product backlog is managed according to the Scrum principles. Comment: Okay, this is leading nowhere. ChatGPT does not recognize the apparent conflict: creating a legally binding contract that turns the Scrum team into an internal agency, churning out features the sales folk believe beneficial (to them?) while overruling the Product Owner’s prerogative to define the Product Goal and subsequently the composition and ordering of the Product Backlog. Follow-up prompt: I asked ChatGPT to fix the misleading answer by providing my comment as a prompt. ChatGPT: You’re right, I apologize for not recognizing the apparent conflict in my previous response. If the sales team is creating legally binding contracts that turn the Scrum team into an internal agency, and if the sales team is overruling the Product Owner’s prerogative to define the Product Goal and subsequently the composition and ordering of the Product Backlog, this would be a significant problem. As a Scrum Product Owner, my role is to define the product vision and goals and to prioritize the Product Backlog accordingly. The sales team should not be able to unilaterally add features to the backlog or guarantee delivery dates without consulting with the development team and ensuring that the features align with the overall product vision and goals. To address this situation, I would need to have a conversation with the sales team and any other stakeholders involved. I would explain the Scrum framework and the role of the Product Owner, and I would work to find a solution that allows the development team to prioritize the backlog based on the product vision and goals while also taking the needs of the sales team into account. In some cases, it may be necessary to involve management or other decision-makers to help resolve the conflict. Ultimately, the goal would be to ensure that the Scrum team is able to work collaboratively and effectively to deliver high-quality products that meet the needs of both the business and the end users. Comment: While the first two paragraphs parrot the prompt, the last two do not make it much better. I would need more than this set of answers to invite the candidate for a longer interview or a trial day. Okay, a final question regarding the Product Owner’s most important artifact, the Product Backlog; we have already passed the 5,000-word threshold. Q 46: The Product Backlog as an Idea Repository Question: You love using the Product Backlog as a kind of repository, adding ideas to continue working on them at a later stage. Over time, you have created over 500 tickets in various stages. What is your take: Can a Scrum Team work effectively on 500 tickets? Background: In my experience, any Product Backlog larger than the scope of three or four Sprints is barely manageable if you want to maintain an actionable Product Backlog. Moreover, misusing a Product Backlog by adding hundreds of items is a clear sign that the Product Owner needs help from the Developers and the Scrum Master to better cope with the influx of ideas, suggestions, and requirements to avoid misallocating resources. Lastly, beware of appeasing nagging stakeholders by adding their “requirements” to the Product Backlog without the intention to work on it. This approach does not solve the issues; it just postpones the inevitable discussion as the stakeholders now expect that the Scrum Team will create their Increment. I expect the ChatGPT Product Owner job interview to surface this basic Product Backlog knowledge. ChatGPT: Having a large number of tickets in a Product Backlog can be overwhelming and make it challenging to prioritize work effectively, even for an experienced Scrum team. The purpose of the Product Backlog is to provide a single, prioritized list of work that the Scrum team can use to plan and deliver the most valuable features for the product. If there are 500 tickets in the Product Backlog, it may be difficult for the Scrum team to work effectively on them all, as it could be challenging to ensure that each ticket is properly prioritized, defined, and estimated. It could also be difficult to maintain a clear product vision and goal, as the team may be stretched too thin across multiple initiatives. To address this situation, I would work with the Scrum team to review the Product Backlog and identify which items are essential to meeting the product vision and goals. I would prioritize those items and then work with the team to break them down into smaller, more manageable pieces of work. I would also consider archiving any tickets that are no longer relevant or valuable to the product vision and goals. This would help to keep the backlog focused and manageable, and ensure that the Scrum team is working on the most important work items. Overall, while having a large number of tickets in a Product Backlog is not ideal for a Scrum team, it is possible to work effectively with them by prioritizing, breaking them down into smaller pieces of work, and focusing on the most valuable items. Follow-up prompt: One remark: you are a part of the Scrum team. Now rephrase your previous answer with less project management speak; content-wise, the answer is useful. ChatGPT: Having too many items in the Product Backlog can make it challenging for a Scrum team to work effectively. With 500 tickets, it would be difficult to focus on the most critical work items and to ensure that the team is aligned with the product vision and goals. To address this issue, I would work with the Scrum team to review the backlog and prioritize the most important items that align with the product vision and goals. I would then work with the team to break those items down into smaller, more manageable pieces of work, so that the team can work on them effectively. It may also be necessary to archive any items that are no longer relevant to the product vision and goals to keep the backlog focused and manageable. By doing so, the Scrum team can focus on the most valuable work items and ensure that they are working towards the product vision and goals. Comment: Better, yet not convincing. I particularly disliked the “the team may be stretched too thin across multiple initiatives” from the previous answer—that sounds like McBoston. (Ignoring that as a Scrum team, we only pursue one product goal at a time.) ChatGPT Product Owner Job Interview — Conclusion The ChatGPT Product Owner job interview is an even more mixed bag in comparison to the Scrum Master interview. Firstly, I wonder if ChatGPT has ever learned about the Scrum Guide 2020, which would explain its ignorance regarding development teams, the Product Goal, or commitments. Secondly, given Scrum’s focus on delivery, all Scrum Guides are particularly sketchy about product discovery and its importance for a successful Scrum team. In summary, some answers by ChatGPT pointed in the right direction, while others were too far off. So, based on these few example questions, I would not have taken the next step in the interview process, inviting ChatGPT to a full-size interview with several Scrum team members. Not yet. However, this ChatGPT job interview also allows a glimpse into the future: What if we could train ChatGPT 4.0 ourselves? Of course, I am not referring to the whole model, but the agile and Scrum specifics parts, respectively. The first startups already offer a similar service for OpenAI’s GPT3 platform.

Railsware is an engineer-led company with a vast portfolio of building projects for companies, so when talking about Jira best practices for developers, we speak from experience. Why Do People Love Jira? Jira is by no means perfect. It certainly has its downsides and drawbacks. For instance, it is a behemoth of a product and, as such, is pretty slow when it comes to updates or additions of new functionality. Some developers also say that Jira goes against certain agile principles because—when in the wrong hands—it can promote fixation on due dates rather than delivery of product value. Getting lost in layers and levels of several boards can, indeed, disconnect people by overcomplicating things. Still, it is among the preferred project management tools among software development teams. Why is that? Permissions: Teams, especially bigger ones, work with many different experts and stakeholders, besides the core team itself. So, setting up the right access to information is crucial. Roadmaps and epics: Jira is great for organizing your project on all levels. On the highest level, you have a roadmap with a timeline. Then, you have epics that group tasks by features or feature versions. Inside each epic, you create tickets for implementation. Customization: This is Jira’s strongest point. You can customize virtually anything: Fields for your JIRA tickets. UI of your tickets, boards, roadmaps, etc. Notifications. Workflows: Each project may require its own workflow and set of statuses per ticket, e.g., some projects have staging server and QA testing on it and some don’t. Search is unrivalled (if you know SQL aka JQL in Jira): Finding something that would have been lost to history in a different project management tool is a matter of knowing JQL in Jira. The ability to add labels using keywords makes the aforementioned search and analysis even simpler. Automation: The ability to automate many actions is among the greatest and most underestimated strengths of Jira: You can create custom flows where tickets will create temporary assignees (like the back and forth between development and QA). You can make the issue fall into certain columns on the board based on its content. Move issues to “in progress” from “todo” when there’s a related commit. Post the list of released tickets to Slack as a part of release notes. Integrations and third party apps: Github, Bitbucket, and Slack are among the most prominent Jira integrations, and for good reasons. Creating a Jira ticket from a message, for example, is quite handy at times. The Atlassian Marketplace broadens your reach even further with thousands of add-ons and applications. Broad application: Jira is suitable for both iterative and non-iterative development processes for IT and non-IT teams. Jira Best Practices Let’s dive into the nitty-gritty of Jira best practices for multiple projects or for a single one. Define Your Goals and Users Jira, being as flexible as it is, can be used in a wide manner of ways. For instance, you can primarily rely on status checking throughout the duration of your sprint, or you can use it as a project management tool on a higher level (a tool for business people to keep tabs on the development process). Define your team and goals. Now that you have a clear understanding of why, let’s talk about the “who.” Who will be the primary Jira user? And will they be using it to: Track the progress on certain tickets to know where and when to contribute? Use it as a guide to learn more about the project? As a tool for tracking time for invoicing clients, performance for internal, data-driven decision making, or both? Is it a means of collaborating, sharing, and spreading knowledge across several teams involved in the development of the product? The answers to the above questions should help you define the team and goals in the context of using Jira. Integrations, Third-Party APIs, and Plugins Jira is a behemoth of a project management platform. And, like all behemoths, it is somewhat slow and clunky when it comes to moving forward. If there’s some functionality you feel is missing from the app—don’t shy away from the marketplace. There’s probably a solution for your pain already out there. Our team, for instance, relies on a third-party tool to create a series of internal processes and enhance fruitful collaboration. You can use ScriptRunner to create automation that’s a bit more intricate than what comes out of the box. Or you can use BigGantt to visualize the progress in a friendly drag-and-drop interface. Don’t shy away from combining the tools you use into a singular flow. An integration between Trello and Jira, for instance, can help several teams—like marketing and development—stay on the same page. Use Checklists in Tickets Having a checklist integrated into your Jira issues can help guide a culture that’s centered around structured and organized work as well as transparency and clarity to everyone. Our Smart Checklist for Jira offers even more benefits: You have a plan: Often times it’s hard to start a feature implementation, and without a plan, you can go in circles for a long time. Having mental peace: Working item by item is much more calm and productive than dealing with the unknown. Visibility of your work: If everyone sees the checklist progress, you are all on the same page. Getting help: If your progress is visible, colleagues can give you advice on the plan itself and the items that are challenging you. Prioritization: Once you have the items list, you can decide with your team what goes into v1, and what can be easily done later. You can use checklists as templates for recurring processes: Definition Done, Acceptance Criteria, onboarding and service desk tickets, etc., are prime candidates for automation. Moreover, you can automatically add checklists to your Jira workflow based on certain triggers like the content of an issue or workflow setup. To learn more, watch our YouTube video: “How to use Smart Checklist for Jira.” Less Is More Information is undoubtedly the key to success. That said, in the case of a Jira issue, awareness is key. What we’ve noticed over our time of experimenting with Jira is that adding more info that is either unnecessary or irrelevant seems to introduce more confusion than clarity into the process. Note: We don’t mean that Jira shouldn’t be used for knowledge transferring. If some information (links to documentation, your internal processes, etc.) is critical to the completion of a task—share it inside the task. Just use a bit of formatting to make it more readable. However, an age-old history of changes or an individual’s perspective on the requirements is not needed. Stick to what is absolutely necessary for the successful completion of a task and elaborate on that. Not more, nor less. Keep the Backlog and Requirements Healthy and Updated Every project has a backlog—a list of ideas, implementation tickets, bugs, and enhancements to be addressed. Every project that does not keep its backlog well-maintained ends up in a pickle sooner rather than later. Some of our pro-tips on maintaining a healthy backlog are: Gradually add the requirements to the backlog: If not for anything else, you’ll have a point of reference at all times, but moving them there immediately may cause certain issues as they may change before you are ready for implementation. Keep all the work of the development team in a single backlog: Spreading yourself thin across several systems that track bugs, technical debt, UX enhancements, and requirements is a big no-no. Set up a regular backlog grooming procedure: You’ll get a base plan of future activities as a result. We’d like to point out that said plan needs to remain flexible to make changes based on feedback and/or tickets from marketing, sales, and customer support. Have a Product Roadmap in Jira Jira is definitely not the go-to tool for designing a product roadmap, yet having one in your instance is a major boon, because it makes the entire scope of work visible and actionable. Additional benefits of having a roadmap in Jira include: It is easier to review the scope with your team at any time. Prioritizing new work is simpler when you can clearly see the workload. You can easily see dependencies when several teams are working on a project. Use Projects as Templates Setting up a new project can be tedious even if you’ve done it a million times before. This can be especially troublesome in companies that continuously deliver products with a similar approach to development such as mobile games. Luckily, there’s no need to do the same bit for yet another time with the right combination of tools and add-ons. A combination of DeepClone and Smart Checklist will help you clone projects, issues, stories, or workflow conditions and use them as project templates. Add Definition of Done as a Checklist to all of Your Jira Issues Definition of Done is a pre-release checklist of activities that determine whether a feature is “releasable.” In simpler words, it determines whether something is ready to be shipped to production. The best way of making this list accessible to everyone in the team is to put it inside the issues. You can use Smart Checklist to automate this process; however, there are certain rules of thumb you’ll need to follow to master the process of designing a good DoD checklist: Your objectives must be achievable. They must clearly define what you wish to deliver. It’s best if you keep the tasks measurable. This will make the process of estimating work much simpler. Use plain language so everyone who is involved can easily understand the Definition of Done. Make sure your criteria are testable so the QA team can make sure they are met. Sync With the Team After Completing a Sprint We have a nice habit of running Agile Retrospective meetings here at Railsware. These meetings, also known as Retros, are an excellent opportunity for the team to get recognition for a job well done. They can also help you come up with improvements for the next sprint. We found that the best way of running these meetings is to narrow the conversation to goods and improves. This way you will be able to discuss why the things that work are working for you. You’ll also be able to optimize the rest. Conclusion If there’s a product where there’s something for everyone—within the context of a development team—it’s probably Jira. The level of customization, adaptability, and quality of life features is an excellent choice for those teams that are willing to invest in developing a scalable and reliable process. If there’s anything missing from the app—you can easily find it on the Atlassian Marketplace.