Product Owner - Agilonomics

Is Product Ownership Your Ideal Career? A Comprehensive Guide for Aspirants

November 1, 2023 No Comments

The Product Owner (PO) role in Scrum is like a puzzle waiting to be solved. It’s a role that’s both vital and enigmatic. Is it different from a Product Manager’s job, or are they two sides of the same coin? Can it be played solo, or is a team approach the key? Do you need to be a product management pro, or is adaptability more valuable? Is it a full-time commitment, and how closely should a dedicated PO work with their development team? In this blog, we’ll demystify the Product Owner’s journey, answering these questions and more, helping you determine if this role aligns with your aspirations, providing clarity and guidance to help you determine if this could be your ideal career path. Skill #1: Visionary Prowess Product Owners are the visionaries of Agile. They see beyond the now, charting a course to a brighter future for their teams and companies. As a Product Owner, you’ll inspire and lead, turning ideas into goals and shared dreams into reality. As a famous visionary leader, Walt Disney once said, “All our dreams can come true if we have the courage to pursue them.” Similarly, Product Owners transform visions into accomplishments, steering their teams towards success. Learn more about the qualities of a good Product Owner. Skill #2: Profound Business and Domain Knowledge Undoubtedly, having a deep understanding of the business, technology, and domain is a skill that should never be underestimated. It’s a skill that can’t be improvised or substituted. For instance, in my experience working with financial and medical clients, it became evident how crucial domain expertise is for Product Owners. In the financial sector, a Product Owner’s grasp of loans, mortgages, and interest rates is indispensable. It enables effective negotiations with stakeholders and the astute prioritization of requirements. On the other hand, in the medical domain, Product Owners need to be well-versed in premium billing and the intricacies of medical insurance liabilities. Now, imagine if these Product Owners swapped roles – it would be far from seamless. Each domain has its unique language, challenges, and intricacies. So, my advice for anyone considering a role as a Product Owner is to start in an industry you’re passionate about, where you have hands-on experience and profound knowledge. Your domain expertise will be your guiding star as you embark on your journey as a Product Owner. Find out why domain knowledge is essential for Product Owners in this article. Skill #3: Building Strong Stakeholder Relationships and Effective Communication In my coaching experience, I encountered a Product Owner who faced significant challenges due to disagreements with stakeholders from various domains. The pressure of constantly navigating conflicting priorities created a tumultuous environment. This highlighted the critical importance of establishing robust relationships with stakeholders and honing negotiation and consensus-building skills. While it’s true that, by definition, a Product Owner holds the reins of prioritization, practical success hinges on alignment rather than dictation. Operating in isolation and acting as a dictator rarely garners favor. In reality, fostering collaboration and consensus among stakeholders is a key element of effective product ownership. Furthermore, this skill extends to the Product Owner’s role as a motivator. They serve as a driving force, inspiring development teams to unite and work cohesively towards the realization of the product’s vision. In essence, a Product Owner isn’t just a decision-maker; they’re a unifying force, fostering collaboration, and ensuring that all parties move harmoniously toward shared goals. Discover more in How do Great Product Owners help their Teams – Part 1. Skill #4: Quick Decision-Making and calling on Choices A good Product Owner makes quick decisions, especially when things get intense. This skill needs three things: empowerment, decisiveness, and the willingness to make hard choices. This courage to decide quickly and make tough calls needs self confidence. It is well supported with your domain knowledge, strong communication skills, and your strong relationships with stakeholders. Even with all that, being decisive is something you develop. Making rapid, tough choices can have big consequences. During my tenure as a Product Coach in the gaming industry, I vividly recall a pivotal moment. We were on the brink of a game launch when a critical bug emerged, threatening to mar the player experience. The team was in a whirlwind, and all eyes turned to the Product Owner for guidance. In the blink of an eye, the Product Owner had to make a tough call: delay the launch by a few days to ensure perfection. It was a challenging decision, but it ultimately safeguarded the game’s reputation. Such swift and resolute decision-making, bolstered by domain expertise and effective communication, is the hallmark of the role. Learn how to steer clear of pitfalls in decision-making in Steering Clear: 10 Pitfalls Every Product Owner Must Dodge But what about technical know-how and Understanding the Team? One more skill often asked about for aspiring Product Owners is technical expertise. Is it necessary for a Product Owner to have prior experience as a developer-programmer, or qa-tester, or a tech lead, etc.? In my perspective, not necessarily. What truly matters is the Product Owner’s ability to comprehend the team’s work and communicate effectively in their language. For instance, if you’re steering a software team as a Product Owner, you don’t have to be a coder, but it certainly helps to understand coding and how the coders discuss and work together. Working with team and being available to them as needed, can help you get better at this skill. Exploring Diverse Paths to Becoming a Product Owner In the realm of Product Owners, many times internal folks are asked to step up to play this role. Why? Well, as explained before, having domain and industry knowledge is key in being a successful Product Owner. Let’s take a look at the various roles that [can] transition into Product Owner role Product Manager to Product Owner One common route is transitioning from a Product Manager to a Product Owner. Product Managers often deal with customers,

Steering Clear: 10 Pitfalls Every Product Owner Must Dodge

October 11, 2023 No Comments

Product Owners have a lot on their plate. In fact, quite a lot! They’re the bridge connecting stakeholders, customers, and users, constantly delving into market insights and data to ensure the product stays on track. Product owners are the glue in team dynamics, always ready to address any queries about ongoing sprint work items. Plus, they make sure there’s a consistent flow of fresh, valuable and clear user stories lined up for upcoming sprints. The realm of a product owner is extensive. Passionate and savvy product owners adhere to best practices to sidestep these 10 critical pitfalls. 1. Product Owners not participating in Sprint Events While the Scrum Guide doesn’t mandate product owners to be present at every daily scrum, competent product owners recognize the value of showing up as often as they can. If I were to handpick the best Scrum teams I’ve collaborated with, I can bet that their product owners were active participants in daily scrums. Surprisingly, there are product owners who opt out of sprint retrospectives. It is equally troubling when teams don’t even extend an invitation to them. Remember, a product owner is an integral cog in the Scrum Team machinery. Their involvement in the Scrum gatherings not only mirrors their dedication to self-betterment but also instills a similar zeal among team members. Commit yourself to steer clear of the First pitfall: Bypassing sprint events. “Success usually comes to those who are too busy to be looking for it.” – Henry David Thoreau 2. Product Owners not empowered and unwilling to make hard decisions Product owners must possess the ability to make swift decisions, ensuring there’s no lag in the development cycle. Equally important is the assurance that their choices won’t be overturned by a senior executive or anyone higher up the ladder. If a product owner’s decisions are regularly overridden, it sends a ripple effect across the team, leading them to perceive decisions as temporary. The Second pitfall: Lacking the Empowerment to Execute the Role Efficiently. When product owners find themselves in this situation, it’s important to engage with the individuals overruling their decisions. One constructive way to approach this dialogue is to jot down distinct product owner duties on individual sticky notes, noting responsibilities such as: Creating and sharing the Product vision Prioritizing the work items Deciding on release timelines Evaluating and commenting on rolled-out features… among others. Next, collectively categorize these notes under columns titled ‘Mine’, ‘Theirs’, or ‘Joint’. Such a well-defined layout of duties often paves the way to garner the necessary autonomy, enabling product owners to thrive in their role. “Leadership is not about being in charge. It is about taking care of those in your charge.” – Simon Sinek 3. Product Owners’ tendency to introduce change mid-Sprint Exceptional product owners assure their development teams that once a sprint plan is set, it remains unchanged. However, in reality, when clients or stakeholders pivot or present new demands, maintaining this assurance can be challenging. The Third pitfall : Introducing Changes Mid-Sprint Rather Than Awaiting the Next. It’s true; on occasion, certain changes are critical and justifiable to be made during an ongoing sprint. Yet, often they’re not. Product owners need to resist the urge to divert a sprint’s course merely due to stakeholder pressure. To minimize these interruptions, product owners should lean on their Scrum Masters, emphasizing that it’s acceptable to resist new additions midway through a sprint. Many Scrum Masters recognize this, but they may hesitate, fearing confrontation. Assure them – standing firm is alright. A personal strategy I employed to manage my impulse to interfere was to document fresh ideas separately. At times, I’d add them to the Product Backlog. On other occasions, I’d just share it with the Scrum Master and brainstormed together to see if it really made sense to bring it up to the team now or during the refinement sessions. Sometimes, merely offloading the thought brings clarity. “Do not let what you cannot do interfere with what you can do.” – John Wooden 4. Product Owners Master the Art of Refusal Establishing a product vision is central to a product owner’s role, aiming to culminate in a solution that resonates with users. However, exceptional product owners grasp that appeasing every request isn’t the path to building what’s genuinely needed. Recognizing that every affirmation also means sidelining another potential feature is crucial. The Fourth Pitfall: Overcommitting by Rarely Declining Requests. A less obvious consequence of giving in to all requests is the unintentional blocking of a future pivotal, yet-to-emerge requirement. Be discerning when determining future commitments. Remember, ensuring the product’s integrity occasionally necessitates a polite decline. 5. Product Owners Navigate with a Far-Sighted Lens Effective product owners always have an eye on the horizon, setting medium-term product objectives as their guiding star. Whether through a detailed product roadmap or another tool, they maintain this vision to steer their decision-making. The Fifth Pitfall: Getting Entangled in Short-Term Sprint Urgencies. I advocate for adopting quarterly product landmarks. This three-month scope strikes the right balance between casting a forward-looking vision and setting targets that feel tangible. More importantly, it creates a timeframe within which progress is not only noticeable but also rewarding. “The greater danger for most of us isn’t that our aim is too high and we will miss it, but that it is too low and we reach it.” – Michelangelo 6. Product Owners Set the Destination, Not the Path The role of product owners revolves around defining ‘what’ needs to be accomplished. The ‘how’ part? That’s the playground of the developers. Let’s say your vision is to launch a smart coffee maker that preps a user’s favorite brew as soon as their morning alarm rings. Your responsibility? Communicate this vision. The nitty-gritty of realization – whether it’s through integrating with smart home systems or using a dedicated mobile app with alarm sync – that’s for the development team to innovate on. Evade Pitfall #6: Dictating the Route. Whenever you’re assigning

How do Great Product Owners help their Teams – Part 2

May 18, 2023 No Comments

This is the second part/continuation of the article “How do Great Product Owners help their Teams” For part 1 of the article, please refer to: How do Great Product Owners help their Teams – Part 1 In this second part, we will dive deep into the remaining 5 attributes of great Product Owners that help them help their teams. 6. How Product Owners help their Teams Win with Storytelling Telling stories is an art, and product owners are the storytellers in agile development. But, their storytelling is not just about spinning a yarn. It’s about conveying user needs and requirements to the team in a way that is easy to understand and estimate. This is where user stories come in. I agree with Mike Cohn, “user stories are placeholders for conversations”, and “a reminder to have a dialogue between the product owner and developers” to refine the story and ensure everyone understands how the resulting software will function. A good product owner is a skilled communicator who can translate user goals into a clear, elevating goal for the product. They don’t just recite a list of stories but connect those stories to workflows and how users interact with the system. So, how can product owners improve their storytelling? One approach is to think about how they would explain the product’s benefits to their grandma. Another is to use analogies or metaphors that team members can relate to. With the right stories, product owners can inspire their team and build a shared understanding of the product vision. 7. Motivating and Inspiring: Igniting the Fire Within Your Team As a good product owner, you have the power to inspire and motivate your team to go above and beyond. A motivated team is a high-performing team that can achieve remarkable results. So, how can you light that fire within your team? First and foremost, lead by example. Show enthusiasm, passion, and dedication for the product and the project. Celebrate wins, big and small, and recognize the efforts and achievements of your team members. A simple “thank you” or public appreciation of your team members can go a long way in boosting their morale. Additionally, create a positive and inclusive work environment. Foster a culture of trust, collaboration, and open communication. Encourage creativity and innovation by giving your team the freedom to experiment and take calculated risks. Remember, a team that feels valued and empowered will be motivated to deliver their best work. As Steve Jobs once said, “The only way to do great work is to love what you do.” So, inspire your team, unleash their potential, and watch them thrive. 8. Decisive and Willing to Make Hard Decisions: The Sign of a Strong Product Owner In the fast-paced world of product development, tough decisions are inevitable. As a good product owner, you must have the courage and conviction to make those decisions, even when they are challenging. Decisiveness is key to maintaining momentum and keeping the project on track. Trust your instincts, gather relevant data and insights, and be confident in your judgment. Avoid analysis paralysis and the trap of seeking perfection. Sometimes, a well-informed decision made in a timely manner is better than waiting for perfect information. Remember, the goal is to maximize the value of the product and deliver exceptional outcomes. Embrace the responsibility of making difficult choices and communicate them effectively to your team. Your ability to make tough decisions will earn you the respect of your team and stakeholders alike. As Winston Churchill once said, “Courage is what it takes to stand up and speak; courage is also what it takes to sit down and listen.” So, be decisive, listen to different perspectives, and make the hard decisions that propel your project forward. 9. Taking an Economic View: Balancing Business and Technology for Success Being a good product owner means understanding the intersection of business and technology and taking an economic view of project decisions. It’s not just about building features; it’s about delivering value and maximizing return on investment. Consider the cost-benefit analysis of each decision and prioritize features that provide the most significant impact. Collaborate closely with stakeholders to align business goals with technological capabilities. Remember, it’s not about building everything, but rather delivering what brings the most value to the customer and the business. Strive for efficiency and optimize resources by eliminating waste and focusing on high-value activities. Continuously evaluate and reassess the product’s market viability and adjust your strategy accordingly. By taking an economic view, you can ensure that your product remains relevant, competitive, and commercially successful. As Jeff Bezos famously said, “The best customer service is if the customer doesn’t need to call you, doesn’t need to talk to you. It just works.” So, as a product owner, keep an eye on the bottom line and work towards maximizing the value of your product. 10. Building Strong Relationships with Stakeholders: Collaboration for Long-Term Success Building good relationships with stakeholders is crucial for the success of any product owner. It’s not just about delivering a product; it’s about creating long-term partnerships that drive continuous improvement and customer satisfaction. As Helen Keller once said, “Alone, we can do so little; together, we can do so much.” When you collaborate closely with stakeholders, you tap into their expertise, leverage their insights, and align your product with their needs and expectations. By fostering strong relationships based on trust and mutual respect, you create a network of support and advocacy that can propel your product to new heights. This does require active effort and dedication. Take the time to understand their goals, challenges, and constraints. Show genuine interest in their perspectives and demonstrate that their input is valued. Regularly update them on the progress of the product and seek their validation and endorsement. Think of stakeholders as your allies on the journey towards product excellence. Involve them early on, seek their feedback, and listen to their suggestions. Engage in open and transparent

How do Great Product Owners help their Teams – Part 1

May 12, 2023 No Comments

As a self-proclaimed Scrum Master whisperer, I’ve chatted and worked with more development teams than I can count. As a result, I’ve experienced a wide diversity of Product Owners. From the good, the bad, to the downright ugly – I’ve seen it all. One thing is crystal clear, a good product owner can turn a decent project into a masterpiece. Meanwhile, a less than average product owner can sink a project faster than the Titanic. So, what sets the two apart? The secret ingredient to being a successful product owner is an innate ability to understand people’s needs. Whether it’s your stakeholders, customers, or team members – a good product owner knows what they need and makes sure they have it. But, how do they do it? By displaying and living the attributes described below: 1. Easily Accessible to teams – Empowering the teams by being present and available 2. Ability to see the big picture – Envisioning a holistic view of the Product’s goals to drive outcomes. 3. Collaborative team player – A dedicated team player, fostering a collaborative environment to drive success 4. Setting high expectations – Setting high standards to achieve ambitious goals and deliverables 5. Prioritizing / Negotiating and building consensus – Prioritizing tasks, negotiating with stakeholders, and building consensus for successful project completion 6. Storytelling / communicating effectively – Mastering the art of storytelling and communicating complex ideas in a simple and effective manner 7. Motivating and inspiring – Inspiring and motivating team members to work towards a common goal 8. Decisive and willing to make hard decisions – Making tough decisions with confidence and conviction for the project’s benefit 9. Taking economic view to balance business with technology – Balancing business and technology by taking an economic view of project decisions 10. Building good relationships with stakeholders – Building strong relationships and maintaining a good rapport for long-term success Let’s look at these closely 1. Be Available: A Key Trait of Good Product Owners In the fast-paced world of Scrum teams, having an available product owner can make all the difference between project success and failure. Your team needs you to answer their questions, clarify their expectations, and provide support whenever they need it. To build a collaborative and productive relationship with your team, you need to be part of it. Sit closer to your team members when at work and be active in the product development chat groups when away. Regularly attend all the team events. Remember, you’re a Scrum team member and team members expect you to be present and actively participate in Daily Scrum, Sprint Planning, Sprint Reviews and Retrospectives Remember, you are expected to grow into an expert who understands users, customers, and markets; knows the product inside out, is involved in every stage of product development and demonstrates the product knowledge and understanding through conversations. This is much more than writing user stories; it should also show in your ability to demo new functionalities, features during Sprint Reviews. Are you on top of what is needed for you to be connected and available to your team member? 2. Motivate and inspire your team to succeed: The visionary aspect of Product Ownership The best among the Product Owners not only set a clear vision for their teams but carve a path filled with inspiration to drive their teams towards that vision. Remember, a great vision is important as it provides a sense of purpose and direction, but outcomes are driven through actions. Many Product Owners start writing grandiose Steve Jobs style vision. This is not required. A clear, inspiring vision that motivates your team is enough. Remember, If you cannot imagine it, you cannot achieve it! Start with a clear goal. That will help you get to a compelling vision. Example: Alexander Graham Bell had a goal. It was to communicate by transmitting speech across great distances before the end of the century. It was clear and elevating. It inspired him to invent the telephone which revolutionized communication and shaped the future of technology! Make sure your Product Vision just a clear and inspiring, although it needn’t be as grand as Bells’. A few examples of clear, inspiring goals: Design a product that will help reduce carbon emission by 50% in 20 years. Build a product that enables people to learn a new language in 3 months. Design and build a Product that helps solve food waste by 50%. Your Product Vision can evolve over time. Jeff Bezos started Amazon as an online bookstore initially and evolved it over time. Keep the vision flexible but it stays clear and inspiring to the team members. 3. Use the Power of Collaboration: Product Owner Game Changer! Successful Product Owners collaborate effectively with stakeholders. They know that success with product is not only dependent on understanding customers, users, markets, risks and competition but also working closely with teams and collaborating with stakeholers. Collaborating effectively involves listening to stakeholders’ opinions on priorities, features, needs, and concerns. Building trust with team members and creating a shared sense of ownership and purpose will lead to better outcomes. Example: Team might request some dedicated time to refactor code. Do not dismiss it right away. Instead ask good questions to understand the impact of this refactoring and how the value delivered measure up with competing stories you wanted to prioritize, Remember, collaborating is not just about getting to done but also about bonding and building trust with your team and stakeholders. It pays off in the long run. 4. Raise the Bar with Ambitious Goals to achieve Exceptional Delivery: This way you will be able to challenge the team to come up with creative solutions to tough problems. Example: Ask them to create a user interface that is so simple and intuitive that even their grandmother can figure out. Give your team enough time to build work items with quality. Often, the rush to quickly finish committed items hardly leaves them with time to be creative

Qualities, Responsibilities, and Characteristics of a Good Product Owner

April 29, 2023 No Comments

Jeff Sutherland, the co-creator of Scrum says: “The Product Owner is the CEO of the Product”. Therefore, it’s important to choose the right person for the job. Are you ready to take on the role of a Product Owner? Or are you in search of a Product Owner who possesses good product owner qualities, understands the product owner responsibilities, and displays important product owner characteristics? As a Product Owner (PO), you are the central point of product leadership. You are responsible for maximizing the value of the product and driving it towards better economics. But being a good product owner is not just about achieving results, it’s about building a culture of empathy, support, and growth. Let’s take a look at the qualities, responsibilities, and characteristics of a good product owner. The importance of the role of a product owner cannot be overstated. The product owner is the single voice for communicating what to build and in what order to build it. They are responsible for marshalling people and resources to ensure stakeholder value is delivered. A good product owner ensures that the team works on the most valuable backlog items and accepts the completed work in a timely manner. They have the same goal as the team and work to maximize the return on investment. One of the most important responsibilities of a product owner is to manage the product backlog. This involves prioritizing the product backlog and ensuring that it is shared with the team and stakeholders. A good product owner also shares the product vision to align business and the team. They define acceptance criteria and verify that they are met, collaborate with the development team, and collaborate with the stakeholders. A good product owner possesses certain characteristics that set them apart from the rest. They have domain skills and are visionary. They understand that everything cannot be anticipated and have business, technology, and domain expertise. They also have people skills, which enable them to establish good relationships with stakeholders, negotiate and build consensus, communicate effectively, and motivate the team. Decision-making is another critical aspect of the product owner role. A good product owner is empowered to make decisions, willing to make hard decisions, and is decisive. They take an economic view to balance business and technical issues. Lastly, accountability is essential for a good product owner. They accept responsibility for the product, are committed and available, and act like a Scrum team member. A good product owner is not afraid to take ownership and ensures that the team is focused on the right priorities. In conclusion, being a good product owner is a challenging role that requires a combination of above mentioned qualities, responsibilities, and characteristics. To be successful, a product owner must be a visionary with business, technology, and domain expertise, possess people skills, be a good decision-maker, and be accountable for the product. By doing so, a good product owner can create a culture of empathy, support, and growth that drives the product towards better economics and maximizes the value for stakeholders.

The Problem with Requirement Specification Documents

May 4, 2022 1 Comment

The creation of the PRD (Process Requirement Document) is not wrong in itself, but the bigger issue is when it is created and how extensive it is. Traditionally, the Requirement specification documents were created as part of waterfall projects. Assigned project managers or technical leads would write a long document pinning all details or requirements for the product that will be worked upon in the short to mid-term future. This is followed by putting detailed design in place, then coding, integration, testing, deployment… We know where that leads to, right? Coming to the present times, I still see a lot of people all over the world, writing PRDs or CUJs (Critical User Journey) as text documents. PRDs are written exhaustively and drive the work done by teams (often referred to as Agile or Scrum teams). Individual team members interpret the requirements and start working on them. If they find something isn’t clear, then they go to the person who created the document for clarification. There are a number of issues with this approach: 1. Writing PRDs exhaustively to drive product development can be wasteful. Refer to the image below. I was first introduced to this image at a training by Kenneth Reubin. The region – 1 represents a danger zone. Why? Because, at the start of a project, we do not have enough knowledge of what we are actually building, whether customers will like what we build, how the final shape and form of the product will be, etc. But we are exhaustively writing (freezing) the requirements. Do you see the disconnect? Not only is it dangerous, but it is also wasteful, as things will change and a lot of what we are assuming might not hold value as we move forward. The region – 2 indicates that our cumulative product knowledge increases over time, and it is wiser to start with a small set of requirements, work towards creating a prototype, get quick feedback and adjust the direction. If this is what is more useful, then why the heck are we creating such exhaustive requirements in the beginning? 2. The second problem with writing such detailed PRDs is that there is a lot of text to read. Usually, different people read such documents on their own and only bring up items they do not understand or need clarification on. But, what about the rest of the items in the document? Research shows that people misinterpret quite a few things based on their understanding and move forward with it. To understand this, let’s refer to the following images, first introduced to me by my mentor Jeff Patton: Per the images above, you can see how people can misinterpret text documents and this can result in lack of shared understanding and alignment, which can negatively impact the health of products. I recently worked at a large enterprise where senior team members are required to create exhaustive PRDs for their teams. A single technical team member then studies that doc on his / her own and starts to implement the code. No one else in the team knows much about the details in the doc, as they have been handed their own docs on projects they will solely own. This creates silos in a group of people who call them as a team but are only a working group. The team meets weekly for a sync-up in which everyone talks about the progress they have made and what impediments they are facing. They also give a Red/Yellow/Green type status on whether they are on target towards delivering the project in 6-9-12 months. Often with only a few months remaining, the team members call out that they will not be meeting the original deadline. PRD driven development based on siloed understanding of the requirements leads to such situations. Estimating a humongous piece of work will carry a lot of uncertainties. More the uncertainty, bigger are the unknowns and larger is the chance of that big piece not delivered on time. Instead, strive to build a shared understanding. Tell stories, do not just write them. Sketch, record, use whiteboards. Discuss visually for alignment. Create story maps and do not freeze or hide them. Continue to update and refer to these maps and make them the source of truth. Ask different stakeholders to walk through these maps to validate the assumptions. Slice the map to target desired outcomes as shown below: Did you notice that every release slice is functional (has the shape and form visible)? And outcome driven? Working in such manner is conducive towards building a shared understanding and should be foundational to effective product strategy. Conclusion: Invest in techniques that create shared understanding and empower the developers to write code with empathy. Create visual shared understanding and maintain those artifacts as the source of truth that feeds the Product Backlog. Remember, a flat Product Backlog is a trap. The 2 dimensional journey maps are contextual and help with alignment and validate our assumptions. They obviate the need to create extensive Product Requirement Documents (PRDs) upfront. In addition to the new ways of working, Scrum Masters must continue to challenge the status quo and coach teams, departments and organizations to let go of exhaustive textual documents that reduce visibility, understanding and lead to fake project estimations and roadmaps that are never met. Amitabh (Amit) Sinha is a servant leader entrepreneur, visionary, mentor, trainer and coach. Amit is highly passionate about Agile, its principles, values, and the human side. Amit is a people champion and strives to bring out the best in his teams. Amit leverages his expertise in Agile, Scrum, Kanban and people skills to increase team effectiveness and happiness. See more

The DEEP Qualities of a Product Backlog

July 26, 2021 No Comments

The most popular and an important artifact in Scrum, the product backlog is never complete. It is ever evolving, as a project’s requirements or environment evolves and changes. It is simple yet purposeful, if used wisely. It lists down all the features, functions, requirements, environment, remediating defects and more. Put simply, it is a prioritized list of work remaining that is necessary to bring the product to life. A high functioning product backlog has four main qualities of a description, estimation, order, and is constantly updated, which helps ensure that the details are always aligned with the big picture. This is represented by DEEP* – Detailed Appropriately, Estimated, Emergent and Prioritized. *DEEP acronym was coined by Mike Cohn and Roman Pichler Detailed Appropriately – Product backlog items are detailed in such a way that higher priority items are more granular and detailed than lower priority ones. The lower the priority, the less detail it carries. Estimated – Product backlog items are estimated. Estimates are not final and often expressed in story points or ideal days (the number of days of effort that it would take to get a story done if the team worked with no interruptions). Knowing the size of the items helps prioritizing and planning the release. While lower-priority items will have less precise estimates than higher-priority items in the top of the backlog, all should still have a rough estimate. Emergent – Product backlog is organic; it constantly evolves, changing frequently as new items are discovered and added based on user and customer feedback. Existing items are reprioritized, modified, refined or removed – continually. Prioritized – Product backlog items are prioritized. The most important and highest priority items are implemented first. These are found at the top of the backlog. Once an item is done, it can be removed from the backlog. Lesser priority items which can be considered later in time can be found towards the bottom of the product backlog. Teams always complete the highest priority items first to ensure that the value of the product is maximized. Though the whole Scrum Team collaborates and contributes to grooming, maintaining a product backlog is the responsibility of the Product Owner. 10% of the Scrum Team’s availability and capacity is allocated for grooming. Since grooming is a continuous process in the sprint, the Product Owner continuously updates and refines the product backlog. Ensuring that the product backlog is DEEP through regular grooming sessions helps establish that the product backlog does not become a black hole of redundant, unnecessary and useless items, features and stories. Maintaining a well groomed DEEP backlog will help you succeed with Agile. Amitabh (Amit) Sinha is a servant leader entrepreneur, visionary, mentor, trainer and coach. Amit is highly passionate about Agile, its principles, values, and the human side. Amit is a people champion and strives to bring out the best in his teams. Amit leverages his expertise in Agile, Scrum, Kanban and people skills to increase team effectiveness and happiness. See more

Product Owner or Business Analyst

November 23, 2020 No Comments

BUSINESS ANALYST The Business Analyst (BA) and similar (related) roles (SA, BSA etc.) have gained prominence over the past few years. One of the reasons for this to have happened is that the Agile Product Owner(PO) role has been on the weaker side. With rapid growth of Agile (especially Scrum) it has been difficult to quickly grow strong Product Owners. As a result organizations have been giving this role to proxies. Technical Leads, Project Managers, Team Managers and even Scrum Masters have been asked to step up and fill this role. Technical Leads and Team Managers often fail to understand the business and Customers well and start promoting non functional or technical requirements (aka – dark stories). On the other hand, even experienced POs sometimes fail to meet the expectations from “Scrum” – Expert knower of – Domain, Technology and Business Requirements, Decisive, … the list goes on. One of the fallouts of these several factors was that the PO role often lacked skills in translating the business requirements to technical terms that teams could understand easily. BAs bridged this gap to some extent. They were trained to understand the business requirements and also easily translate those to language that made sense to developers Although, this support role worked out well, it would (at times) result into anti patterns. One of this is where the PO would just take the back seat and be a backlog wrangler while the BA would start breaking down the bigger backlog items into smaller pieces and driving the requirements. Often this would result in the team asking BA for clarifications and even prioritization needs. This would weaken the PO role, and confused the team. It is important to understand that while the BA role is an important one and has found a reason to thrive, it should still be within well defined guard rails so the PO role is played the right way to create strong Scrum helping teams and organizations succeed with Agile. “Ownership” is a different ball game The Product owner is a mature and yielding role who needs to know what it means to ‘Own the product’. A Scrum Product owner is The Voice of the Customer Solely responsible for maximizing the value of the product by understanding the markets, customer needs and prioritizing items in the Product Backlog to best achieve goals and missions Responsible for creating a vision and aligning business and the team to the vision. Accountable for a creating high level persona based requirements in the format of user stories and map that backlog to a roadmap A Quick and smart decision maker for the team. Answerable to the users and customers. A scrum team ideally consists of Product owner , Development team and Scrum master. However when organizations moved towards Agile transformation , they faced a challenge in positioning their existing BAs or BSAs in a scrum team. Some organizations scaled up their business domain experts in to the role of Product Owners by providing necessary trainings and clarifying the expectations out of the PO role. Few organizations hired new product owners but at the same time had their business system analyst or technical solution architect in the team without defining the space and scope of their job duties which caused chaos. A BSA is a vital role and is inevitable if they stick to their boundaries in an agile team. The scope and responsibilities for them needs to be clearly handed out to prevent the anti pattern havoc. They need to work with a gracious handshake with the product owner. Agile is very flexible to accommodate other roles but ideally these other roles are considered to be part of the development team just like how the QAs are. With that said, the product’s pastoral staff remains in the hands of the product owner. They decide “what” is to be brought in to the sprint backlog. Team can negotiate but the final decision is the PO’s. The system analyst or solution architect will take care on the “how” part of product development along with the team. Now that reminds of a very common question that people ask me – Can a Business Analyst or Business System Analyst grow in to the role of a Product owner? The answer is Yes with ‘all the might‘. When I say all the might, it means to understand the shoes of a product owner before stepping in to it! Amitabh (Amit) Sinha is a servant leader entrepreneur, visionary, mentor, trainer and coach. Amit is highly passionate about Agile, its principles, values, and the human side. Amit is a people champion and strives to bring out the best in his teams. Amit leverages his expertise in Agile, Scrum, Kanban and people skills to increase team effectiveness and happiness. See more