free
Resources

ABC
Conscious Leadership
Training Schedule
Contact

Ten Tips from a SAFe Product Owner: How to Truly Own Your Role

February 25, 2025 3 Comments

The SAFe framework distinguishes between the Product Owner (PO) and Product Manager (PM) roles—where the PM defines the vision and strategy, and the PO focuses on execution and delivery. But great product leaders like Marty Cagan and Jeff Patton challenge this division. They believe a true product leader does both—owning not just the backlog, but the why, what, and how behind the product. So, where does that leave a SAFe Product Owner? If you’re simply taking requirements from a PM and feeding them into a backlog, you’re not owning anything—you’re just a horse saddler handing over a polished list to your team. But if you step up, own the vision, challenge assumptions, and drive real value, you become a true Product Owner in every sense. Here are ten practical ways to make sure you bring real value to your team and organization—without getting boxed into a narrow execution role. 1. Own the Product, Not Just the Backlog A backlog is just a list. A great PO is more than a list manager. Ask yourself: Push beyond backlog management. Drive meaningful conversations about outcomes, not just output. 2. Bridge the Gap Between Execution and Strategy SAFe may define separate PO and PM roles, but in reality, great POs don’t just “take orders” from PMs. If something doesn’t make sense, challenge it. 3. Fight for Customer Value Over Feature Output SAFe teams often fall into “feature factory” mode—churning out backlog items without questioning their impact. Break that cycle. 4. Collaborate Relentlessly with Developers Great teams don’t just build what’s written—they solve problems together. Your job isn’t just writing stories; it’s ensuring they’re understood, refined, and meaningful. 5. Become an Expert on Your Users If you don’t deeply understand your users, you’re just moving tickets around. You should be able to defend every single backlog item with a clear “why.” 6. Stop Over-Reliance on SAFe Artifacts SAFe gives helpful structures, but don’t let them turn into mindless processes. Make SAFe work for you, not the other way around. 7. Work Side-by-Side with the PM, Not Under Them If your PM is making all product decisions while you’re just refining user stories, you’ve lost ownership. 8. Influence Without Authority SAFe POs don’t always have direct decision-making power. That’s fine—great POs influence instead of command. 9. Think Business, Not Just Features The best POs think beyond user stories—they think about business impact. If you start thinking like a product strategist, you’ll gain credibility and influence. 10. Never Stop Learning & Challenging the System A great SAFe Product Owner doesn’t just follow the framework blindly. They adapt, question, and improve it. Final Thoughts: Be More Than a Backlog Manager SAFe segregates PMs and POs into 2 separate roles, but that doesn’t mean you have to limit the value you can give to your teams and the organization. If you only manage the backlog, you’re just a horse saddler. If you own the product, challenge decisions, and drive customer value, you become a real Product Owner. 👉 Want to see how strong Product Ownership transforms teams? Own the role. Shape the product. Drive real impact. 🚀  

AI in Agile: Are You Innovating or Just Automating Mistakes?

February 18, 2025 2 Comments

AI in Agile: Racing Faster… But in the Wrong Direction? A few months ago, I was invited to observe how AI was being integrated into a Fortune 100 company’s operations. When I walked into the conference room, the whiteboards were covered—flowcharts, decision trees, AI integration plans, pages upon pages of automation roadmaps. The team was waiting for me to be impressed. “What do you think?” one of the senior engineers asked, expecting validation. I looked around, scanning the intricate maze of diagrams. Then, I said the only thing that came to mind: “I think you’re missing the whole point.” “What do you mean, Amit?” “Tell me, where will AI give the most value? In automation, or in helping us explore how to optimize?” Silence. A few nervous chuckles. But they knew exactly what I meant.They had mapped their existing world in painful detail. Not once had they asked whether that world even needed to exist. That’s the problem with how most organizations are approaching AI today. They assume faster means better. But AI applied to an inefficient process does not create innovation—it just scales inefficiency at an exponential rate. Turbocharging Bad Decisions: The AI Pitfall Agile Teams Ignore Most organizations are not innovating with AI—they’re just automating old inefficiencies. It’s the corporate equivalent of turbocharging bad decisions—using cutting-edge tools to speed up a flawed process instead of rethinking if that process even needs to exist. This is exactly what I saw in the Fortune 100 company I worked with. They were obsessed with automating their call support workflows as quickly as possible. But in their rush, no one stopped to ask: It took one conversation—one heated debate among their tech team—to uncover the real problem. They weren’t using AI to innovate; they were using it to copy-paste inefficiencies at scale.And that’s the real danger. The illusion of progress.If you take a broken, outdated process and use AI to make it move faster, what will you really achieve?Not much. You’ve automated waste. AI Shouldn’t Follow Rules—It Should Challenge Them Don’t use AI to replicate human inefficiencies at scale—use AI to challenge them. But that requires a mindset shift: This is exactly what was happening at this fortune 100 company. Once we stopped treating AI as a mere accelerator and started using it as a partner that could analyse, something changed. Instead of blindly automating all workflows, the company re-engineered AI to analyze processes first, detect redundancies, and flag unnecessary steps. Instead of scaling inefficiencies, they were now systematically removing them. Here’s what we did differently: The impact was clear: AI didn’t just automate work—it helped redesign how work happens. If AI Isn’t Challenging You, You’re Using It Wrong AI is a force multiplier. But what are you multiplying? Are you scaling efficiency, or are you scaling waste? Most companies get caught in the automation trap—pushing AI to move faster without stopping to ask: Is this even the right direction? I believe AI in Agile should be more than just a fancy speed boost—it should be a thought partner. It should tell us: If your AI isn’t challenging you, you’re not using it right.So, before you invest in AI, ask yourself one hard question:Are you using AI to transform work? ORAre you just making bad decisions… faster? Share your experience! Have you seen AI used to redefine work, or just to replicate it? Drop a comment—I’d love to hear your thoughts. Amitabh Sinha (Amit) is a trusted Agile transformation expert and AI strategist, known for helping organizations cut through the hype and unlock real, tangible value from Agile and AI. With decades of experience as a software engineer, Agile coach, and product leader, he brings a deep technical understanding and a practical, no-nonsense approach to driving meaningful change. Amit and his team help companies “adopt AI in Agile”—by ensuring they integrate it the right way. Connect with Amit for tailored, high-impact solutions that actually work.

Agile SOW

January 14, 2025 4 Comments

Software projects are becoming increasingly complex. This complexity demands Agility. Agility translates to faster product increments, shorter review cycles, end-to-end picture of the product which essentially means incremental and iterative delivery. Quality needs to be built in. End user and customer engagement (via the PO) is indispensable for both building the “right product” and the “product right”. While the IT operations are going through a paradigm shift towards Agile, has the documentations such as SOW  changed to cater the needs of Agile world? What is an SOW? Statement of Work (SOW)  is a legal binding contract between  an Organization and a contingent worker or a vendor that dictates the directions of how the work will be done. So, for Agile projects, the less you write, the better off you are. Remember, the mantra is: “Less is more”. Having said that, an SOW for an incrementally-delivered project should consider the following facts when drafting one. Including a Release plan in SOW The SOW can include a statement that as the teams start working, they will put together a release plan to provide an insight on how the timelines look at this time. A note in bold must indicate that this is how it looks at the very beginning and that this release plan will be updated after every sprint and the updates will be made available to all stakeholders. The release plan should try to cover the below facts: Initially the big blocks of work lower in the backlog will be Tshirt sized and the teams may want to have a rough mapping of Tshirt sizes to get an arbitrary value of story point. Alternatively, affinity sizing can be used to quickly and roughly estimate a large initial backlog so the teams have some numbers to refer to as they take strides into sprints. With time, as the product emerges and evolves, the PO and stakeholders get better sense of the timelines with updated release plan which has estimates with higher accuracy The team velocity is an important factor for creating the release plan. Prediction of team velocity is possible after first few sprints. A team’s velocity is not same as any other team’s due to various factors like experience, number of members in team, complexity of product, the technology they are working on, their style of estimation, etc. Velocity plays an important role in Agile release planning. Proper coaching by a servant leader Scrum Master is highly essential for a Scrum team to estimate consistently, plan and commit to correct capacity and then deliver to its commitment. This brings up a stable velocity and predictability which in turn provides confidence to the PO and stakeholders and they look forward to the updated Agile release plan at the end of every sprint. Servant leader Project managers and Scrum Masters must include only the details in SOW that are of Agile nature. There should be no pressure from the leadership to include details that SMs/PMs do not feel confident about. This way the Servant leader SMs won’t be held hostage by not accomplishing timelines and scope they did not think could realistically be included in an Agile SOW. The behavior of the leadership in such companies that want to really adopt a more Agile way of working should be transparent and oriented towards creating a culture where their actions are in sync with their desire to be Agile  Let your SOW be versioned and wait for the signatures till an agreed upon Agile SOW is in place.  The first version of the SOW should be light. A small handful of sentences should suffice. If you do get push back, review your options, some of which could be:  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

Optimizing Workforce Efficiency: Employee Utilization with Agilonomics

Effective “Utilization” of Employees

January 19, 2023 No Comments

Have you heard the phrase? – “Watch the Baton, not the runners?” Translated to development work, it means: “Focus on Idle work, not Idle workers”! (Image 1) I still come across management finding ways to extract most out of their developers by assigning them to multiple projects The thinking is to get 100% utilization out of each worker So, Joe is made to work: 40% on project A, 30% on project B, and 30% on project C And, this way Joe is 100% utilized! Such a mindset is flawed Here are two different ideas to explain this: Theory#1: Queueing theory and utilization (Image 2) As you can see, when queue sizes are small(optimum), utilization looms around 70% – 85%. Work continues to flow optimally. A little surge here and there is absorbed easily With further increase in queue size, utilization shoots over to 100%.  Things slow down considerably and bottlenecks are seen This means that if Joe is close to 100% utilized, then it will slow down the delivery or completion of all the items he is working on Furthermore, if Joe’s team mates Harry and Nancy are all (also) 100% utilized, then the team cannot handle critical items that suddenly pop up and need attention And, hence, Management needs to focus on idle work and not idle workers! Theory#2: Context switching 40% + 30% + 30% does not add up to 100% IT DOES NOT! Why? Because, Joe is a human being and not a “resource” There is context switching and we know that loss of time due to context switching is pure waste! Image 3 – is from research on multi-tasking done by Clark and Wheelwright (1992) which shows that when working on more than two projects, a person’s time spent on value-adding work drops rapidly Multitasking is an evil and really speaking, everyone is to be blamed and not only the management I once met a developer who was asked to divide his time between 4 different projects, and as a result, couldn’t deliver to his Scrum team commitments but was fine working on the 4 projects as it brought him importance and visibility at the cost of impacting all the projects – spread across 3 Scrum Teams It took several coaching sessions between us that helped him realize that this may negatively impact him in the long run as well and he voiced his new understanding to the management and they set him with just two projects which helped everyone! With these two well researched theories, management and leaders need to reflect on how they utilize their people and best ways to help them be effective! What has been your experience with over utilized workers and multi-tasking? How have you dealt with such a mindset and what have you done about it? (taken from Amit’s Linkedin post “January 12, 2023”)

Scrum Managers: Agile Leadership Roles With Agilonomics

Managers in Scrum

December 28, 2022 No Comments

We all know that the Scrum Team consists of the three main roles – Scrum Master, Product Owner and Developers (erstwhile Development Team)  Where do Managers fit in then?  Many think that Managers do not have a role in Agile and Scrum. Some even say that Managers are not necessary and teams can survive and even thrive without them Well, Agile being “agile”, is all inclusive and so Managers can live and actually help Agile grow and thrive in a number of ways Let us explore all different roles and places where Managers can fit in and how they can positively impact their Agile and Scrum teams and what do they need to avoid that would weaken agility in their environment and organization Manager and Scrum Team: The Manager role has been in place long before Agile and Scrum came into being. Managers were responsible for taking care of people, what they work on, how they accomplish the work and would help with tracking the work However, Agile encourages self organizing teams. Per the Agile manifesto:  The best architecture, requirements and design come from self organizing teams (Principle#11),  and  Build projects around motivated individuals. Provide them with the environment and support they need and trust them to get the job done (Principle#5) Furthermore, the Scrum roles and responsibilities outline the Scrum Master as one who owns the process, team effectiveness and team happiness. This includes conflict resolution, making sure the impediments are resolved in a timely manner, mentoring, guiding, coaching, facilitating, …  You may benefit from reviewing related blogs.  What Does A Scrum Master Do? | Agilonomics and An Ideal Career Path for a Scrum Master | Agilonomics for in-depth understanding of the Scrum Master role Scrum Product Owner is the one who understands the market, the users and customers, brings in the requirements and prioritizes them. He/she creates the vision for the product and aligns it with the team and stakeholders. He/she works with the team to groom the backlog, is available to clarify requirements and accept the “done” work throughout the Sprint The Scrum Master coaches the developers and the Product Owner to work effectively keeping in mind the tenants of Agile, focused on value delivery and team effectiveness What is the role of a Manager in this setup then? And, where and how does a Manager fit in this whole picture?   Well, there are a number of ways Managers show up with Agile teams. I discuss a number of scenarios I have come across with examples and suggestions that can make the role effective Manager as the team boss: Developers report to the Manager and Scrum Master is an independent role with reporting lines in another department (example – PMO) Manager’s micro-managing the team can conflict with the Scrum Master role and create an impediment to Scrum effectiveness. If Scrum Master wants to experiment with the process or coach the team for following Agile Principles but the Manager opposes it, it will weaken the SM role and team effectiveness can suffer It is important that the Manager, Scrum Master and Scrum Master’s boss have a working agreement so that the Scrum Master feels empowered and the role is supported In the case the Scrum Master role is played by one of the developers then the Scrum effectiveness can be weakened further as there is no one for the Scrum Master to intervene if needed. Such Scrum teams work towards only perfecting “doing” Agile Manager as the Product Owner: This is common in many companies where Manager transitions to the PO role since she has been working with the same team managing the what, how and tracking prior to transitioning to Agile Scrum Master belonging to an outside-the-team department such as PMO may find it hard to coach the Manager in Agile ways. Example: Manager failing to agree-upon/cooperate on how to address change and repeatedly brings scope (creeping) in the middle of Sprints and justifying her being the PO, can call the shots on scope. Such reasoning can hamper with correct and effective agility Here, too, having a working agreement with the Manager and PMO can help empower the Scrum Master Again, If the Scrum Master happens to be a developer, then coaching one’s own Manager-cum-PO can be even harder and challenging Manager as the Scrum Master: This is a tough one. There is a conflict of interest in the two roles. A servant leader Scrum Master coaches the team, adheres to the Agile values and principles but experiments with the process to see what works best for his team. He is open to the team challenging his assumptions and disagreeing and in fact uses such disagreements to foster powerful conversations and bond the team However, when this role is played by the team Manager, it is difficult for developers to oppose or challenge the choices the Manager makes. The subtle thought, “my performance review will be impacted if I oppose my Manager”, is always in the back of the mind of the developers Best is to avoid this anti pattern in the roles because however hard you may try, you will find it will never achieve the right balance between the two conflicting roles Manager as both the Scrum Master and the Product Owner: This is a double tough one. One for the reasons mentioned above and second for the two conflicting roles being played by the same person  Scrum Master role is to protect the team from being overly and unreasonably pushed by the PO and stakeholders while the PO role is to push and drive the team to achieve business goals. A delicate tension between the two roles is healthy for effective Scrum Remember, when the same person plays both the Scrum Master and Product Owner roles, it is like being a 2 headed dragon. At any time, one head will end up eating the other. In other words, you cannot be a good Scrum Master and a good Product Owner at the same time! How can a Manager effectively support Agile? Whichever orientation a Manager is in, she

Jobs To Be Done vs User Story Maps – 2

July 8, 2022 No Comments

This is part 2 of the article on JTBD vs. USM For part 1 of the article, please refer to …… Jobs To Be Done vs User Story Maps In this article, we will fully dive deep into what Jobs To Be Done (JTBD)  really is and how it differs from User Story Maps. I will also help show how to use them collaboratively in meeting your needs. JTBD first came out when Clayton Chirstiansen, a professor at Harvard Business School’s Product Management group, set out with his team to understand what ‘needs’ drive people to ‘hire’ a product. Needs are driven by “jobs that need to be done”. In short, Clayton and his team ended up interviewing a number of people buying Milkshakes at a fast food restaurant. They asked each Milkshake buyer, “What jobs do they need done that makes them hire a milkshake?”  While many did not understand what the question really meant, Clayton’s team through observation and talking with customers figured out that people who had to commute long distances early AM needed to buy milkshakes to keep them full till lunch, to have something that takes quite a while to consume, to have something that is easily manageable while driving through the commute……. And that, they were not necessarily buying milkshakes because they were delicious. Here is the video where Clayton talks about Milkshakes! This and other experiments made Clayton and his team conclude that people hire a product because they have a certain job that needs to be done.  This is quite revolutionary.  “The secret to right innovation lies in understanding what causes customers to make choices that help them achieve progress on something they are struggling with in their lives. To get to the right answers, Christensen says, executives should be asking: “What job would consumers want to hire a product to do?” So, in summary, JTBD: User Story Maps (USM) on the other hand, is based on users and their experiences while using a product. USM focuses on specific personas and their story on how they (want to) use your product. A good user story map contains not only the journey but also the experience – challenges, pains, awards and joys the users feel or express while using your product. Although, the USM has no specific set of rules, it is recommended to understand the difference between the sea-level “user steps” (a step that a user takes in the journey of using your product with the intention of completing it once started) and the “backbone” – activity or higher level summary of a group of steps as shown in the image below Fig. xxx – User Story Map for an Air Travel App While both the sea level (user steps) and backbone (higher level summary) are in narrative flow, the backbone actually represents the jobs to be done and provides insights into the deeper needs of customers or users.  The narrative flow of sea level user tasks goes like this: (As a user of this product)  I will do this , and then I will do this, and then I will do this and then…. The narrative flow of backbone (user activity) goes like this: (As a user that wants to get this job done – air travel in this case)  I need to do this , and then I need to do this , and then I need to do this and then … Please refer to the examples below illustrating the above: Looking at these images, one can easily see that jobs to be done are already embedded into the user story maps. Many do not know how to create story maps effectively. If you can build your maps wisely and mark out areas or steps where customers and users experience challenges, pains and have to work around to get through those step(s), you will be able to draw insights on what they want to get done and what needs are not being met for which they have workarounds. Clayton himself has said: “For me, this is a neat idea,” Christensen writes of the Theory of Jobs to Be Done. “When we buy a product, we essentially ‘hire’ something to get a job done. If it does the job well, when we are confronted with the same job, we hire that same product again. And if the product does a crummy job, we ‘fire’ it and look around for something else we might hire to solve the problem.” Many folks who have never experienced story maps and their effectiveness and usefulness in creating delightful products, but know about Jobs To Be Done, use this thinking framework to draw insights. However, they will still need to create some sort of visual alignment for conversations to build a shared understanding.  ou cannot just use JTBD on its own to help others understand a product. Remember, JTBD is a motivation and not a product design! However, people who employ user story maps can easily draw out the jobs to be done Comparison between Jobs to be done vs. User Story Maps  Conclusion:  There’s quite a bit of debate out there on what is a better approach for building a great product, Jobs To Be Done Or User Story Maps. The reason for the debate is due to a lack of proper understanding of how these two approaches work. Looking deeply and objectively, one will find that they are not conflicting but are different ways to understand your customers and user’s real problems and goals, which is part of a good product thinking exercise. A user story map will ideally have included the important jobs a user needs to be done 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

Jobs To Be Done vs User Story Maps – 1

May 18, 2022 2 Comments

This part – 1 of the article explains situations that arise due to lack of ownership for journey mapping exercises. Who should own them?, why should they be done? Etc. The part – 2 of the article discusses in depth the Jobs To Be Done vs. User Story Maps – 2 Part-1 While helping clients with Agile transformation, I focus on a few important aspects, which are outlined below: It is with respect to this last point #4, I often introduce journey (aka user story) mapping concepts and workshops to the leadership. It is usually received with mixed response, and although, people love the workshop, they need some hand holding to get started onto this. We eventually get the product owners to own this and work with a small group of engineering and design leads to get the high level maps in place, which eventually results into exploring deeper area maps (remember: maps, contain maps, contain maps…) that are owned by individual teams as they try to build a shared understanding for the features or products they are responsible for. I also saw resistance from Product Owners to drive the creation of journey maps citing that they already created a PRD (Product Requirement Document) and since it’s all clear in their minds, they failed to understand why it is difficult for engineering and design teams to align with their thinking. The engineering team, on the other hand, complained that the product only provides a document or a one-liner explanation for critical items, and they have to interpret the details on their own. The design teams tended to side with engineering in not having a clear understanding of assumptions made by the product team. Moreover, the design team decided to start driving the creation of the JTBD list involving members from engineering and product through discussions. Let’s distil the issues hidden in the above paragraph:  Firstly, written documents do not create a shared understanding. Writing such documents and making them the basis for alignment is the reason why so many of the products fail to delight the end users and customers, and as such, do not do well in the market. I wrote an article on this: The Problem with Requirement Specification Documents Secondly, Product Owners not wanting to own creating visual artifacts (JTBD, Journey Mapping, etc.) and being more in the role of a secondary observer/participant is quite puzzling. On inquiring a little, I found that the Product teams had bandwidth issues, were overwhelmed in learning a new concept and lacked belief in new ways of thinking to create a powerful version of their product that would highly differentiate them from their competitor’s offerings. This not only needs coaching to understand the value of such activities, but also a commitment from the product leadership to invest time in them. Thirdly, the product leadership failed to understand why their Product Owners should co-drive the journey maps? I asked a few questions:  They realized that missing POs during such journey mapping activity might not give them the desired outcome they want to see while delivering the product! Once this was resolved, the product leadership had two asks: In answer to the first question, I took them through a fun and hands on user story map session. It took around 90 minutes to facilitate this for a big group of 20 people. I have captured this into a 4-minute cartoon video that anyone can find handy. In answer to the second question: Please read the part 2 of this article Jobs To Be Done vs User Story Maps 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

Why sprint reviews are hard?

Why Sprint Reviews Are So Hard ?

March 18, 2022 No Comments

As we know, there are four main Scrum ceremonies: Sprint Planning, Daily Stand up, Sprint Review and Sprint Retrospective. Additionally, we also groom or refine the backlog (Backlog Refinement) which happens throughout the Sprint. The Sprint Review is second to last ceremony in the Sprint. The purpose of the Sprint Review is for an Agile team to show their product increment to the Product Owner and business stakeholders. The idea is, for the team to demo their product increment, features or functionalities and engage the audience in conversation to understand how they feel about it, what they like or dislike about it, what they think is still lacking etc. In the course of this conversation, the team gets valuable feedback, which they use to improve the product in subsequent iterations. Among all the Scrum ceremonies, the one that appears to be the weakest or least effective is the Sprint Review. There are many reasons why Agile teams struggle organizing effective Sprint Reviews. 1. The most critical reason is the inability of Agile teams to create their product keeping the big picture in mind. If one looks at the Product Backlog Items (PBI) of most Agile teams, they will not be surprised  to see that many of those items, called “Stories”, do not give any value to the end user or customer. Even combining a few of these stories does not give much value. Having finished these components, the team demonstrates those bits and pieces to the business stakeholders. Not only is this boring for the audience, they also do not  see much value in it. Imagine somebody is designing and creating a beautiful table, but only shows one leg and half of the top to potential buyers at an agreed upon date. Would you be excited to buy such a product? Will you even be motivated to come back and look at it unless it’s completely done?  I have often seen senior leaders and executives coming to a Sprint review for the first time when a new Agile team demonstrates their completed work. While these leaders praise the team for their accomplishments, you can see a confused look on their faces asking an unspoken question: The senior leaders and executives eventually stop coming to the Sprint Reviews, as they don’t find them meaningful. 2.  The second most important reason for Sprint Reviews to be not attended by senior leaders or relevant stakeholders has to do with the language used during the demo. What I mean here is, that a lot of Agile teams do the demonstration of their product in technical language. They bring up a screen with a Linux prompt and open the code, showing pieces to confirm on how the goal of a Story is achieved. While this could be attractive to other technical team members or even engineering managers, the business folks really do not get much value from it. This is akin to an audience that understands only Japanese, but being invited to a review of a product that is to be given fully in English. Just imagine bringing up a screen with English letters and words being displayed, with the hosting team speaking only in English. Will the Japanese stakeholders come back to such a Sprint Review? – NO! It would be a good idea for the (Business) Product Owner to actually drive the demo. They can work with the team and also speak the language of business stakeholders. Enabling stakeholders to be able to directly interact with the functionality of a product rather than demoing technical code will also be appealing to them. 3. Sprint Reviews being held on the wrong day of the week. Ideally, the Sprint cadence should run from Wednesday to Tuesday or Thursday to Wednesday. The advantage with this cadence is that the starting and ending days do not fall on a Monday or a Friday – the days when people tend to be busy or not easily available. For example, a 2-week Sprint that starts on a Wednesday will end 2 weeks later on a Tuesday. However, many teams, especially new ones, without much experience, tend to start their Sprints on a Monday or a Tuesday. This results in Sprint Review falling on Fridays or Mondays (Ideally the last day of a Sprint)  when senior leaders and relevant stakeholders are busy and unavailable, resulting in poor attendance.  4.  I have also seen that there are certain scaling frameworks in Agile which tend to encourage many teams in organizing their reviews or demos together. I have seen such teams sitting in a big conference room for hours together doing their Sprint Reviews. This is a painful sight to see. Especially so, because most of these teams were component teams and did not have much understanding of how each other’s work contributed to the bigger product. It is difficult to visualize senior leaders and business stakeholders sitting in such reviews for half a day. It would be considered a big waste of their time, and for this reason, attendance for such Sprint Reviews are low. 5. Lack of proper engagement of key stakeholders also results in poor attendance. Most teams call their Sprint Reviews as Sprint Demos. In fact, Sprint Demo has become the more popular name for Sprint Reviews. The whole idea of this ceremony is about engaging your customers and users for a meaningful conversation and taking important feedback that can be critical for the product success. But more often than not, hardly any conversation takes place. How do we break this barrier? One thing that comes to mind is, that, instead of waiting for the entire Sprint Review to be over, teams should take feedback after every item is reviewed. This will not only keep the stakeholders engaged, but will encourage them to provide valuable feedback for each item at the current time.  How often should we do Sprint Reviews? Ideally speaking, Sprint Reviews should be held every Sprint. However, many teams only create components. They do not work by keeping the big picture in mind. Demoing these small components every

A RAMBLE ABOUT METRICS – ZACH BONAKER

October 1, 2020 No Comments

MEASURING AGILE How will you show the progress of agile transformation? How will you measure improvement in teams and people? And how will you avoid the trap of shallow metrics like say:do ratios and velocity? Whether you’ve worked as a manager, coach, or consultant, you’ve likely experienced conflict and confusion over “agile metrics.” Traditional metrics which emphasize personal productivity drive negative behaviors, encouraging us to stay busy with tasks over working together to achieve goals. Meanwhile, leaders feel dissatisfied with popular “agile metrics,” such as velocity and burn-down charts, when they fail to provide the insights desired. This conflict between management and the information generated by metrics is further exacerbated when three common human desires for “measuring agile” inevitably occur: Success Metrics and Improvement metrics While there are many reasons these scenarios may be challenging–and frustrating–to solve, one possible contributor is the failure to distinguish between “success” and “improvement.” By definition, “success metrics” are exactly that: the key measurement which reflects on the interaction (and collaboration) within the system to generate a successful outcome. By taking a measure-up approach to avoid focusing on individuals, we can see whether our system of work is delivering the result we need. Because we’re considering the success of the system, we likely only need one, possibly two, success metrics. Further, such metrics would be relatively long-term in persistence. On the other hand, “improvement metrics” are useful until they no longer are. They exist to help guide us towards reaching a desired state, whether it be behavior, process, or performance. By definition, “improvement metrics” should be relatively short-term in lifespan and may change based on new information gathered. It’s easy to test for an improvement metric: we can state what decision(s) we will make as a result of the metric, plus what conditions would exist for the metric to no longer be useful. An interesting thought which comes to mind: perhaps in the early stages of using agile (and assuming an absence of prior “success metrics”), our success metric might be the length of time before an improvement metric becomes obsolete. I believe this structure of categorizing “success” and “improvement” metrics creates an environment where two beneficial things can happen: To illustrate the second point, consider a scenario which might be familiar: A company shifts from a matrix system of work to teams working in sprints. Once this happens, a manager feels the need to measure team productivity and/or performance. After all, this is a new “process” and the manager wants to make sure it’s effective. To do so, the manager asks teams for a “say:do” ratio: the number of items/points/features/etc predicted versus the total actually delivered. If not success metrics, it is an improvement metrics It’s likely the manager considers this measurement a “success metric.” Therefore, we ask her to explain how the metric represents the interaction of all the parts necessary for success. Assuming our goal is wildly successful software products which our customers love, we likely realize this metric ignores essential contributions of product management, customer support, the degree of disruption the team must manage, and other probable factors. So, if not a success metric, might it be an improvement metric? We explore further: I suspect these conversations might guide the manager to reveal her assumptions about measuring teams aren’t serving her ultimate needs. We then have the opportunity to explore together a more systemic need for measurement, most likely focusing on gathering information to improve, rather than perform. In my experience with agile and “transformation”, whatever that might be sometimes,  I’ve found results tend to improve when we move away from “metrics to manage behavior” and begin using “metrics to help us understand behavior.” This framework of success and improvement metrics can help us achieve exactly that outcome. About the Author Zach Bonaker Agile Coach Zach Bonaker is a “benevolent trouble-maker” based in San Diego, California, USA and has more than 10 years of experience assisting organizations with achieving their goals through improved working conditions and team-centric systems of work. With experience guiding Fortune 500 companies to multi-million dollar startups, Zach draws upon agile principles, relationships, and systems thinking to redesign structures into safe, collaborative environments. Zach is an international conference speaker, frequent podcast guest, and contributor to the global agile community. When he isn’t thinking about next-generation agile ideas, Zach can be found enjoying the sunny California weather and connecting with people all over the world.

New to agile?
Trainings & Certifications
More...
Get Agile Wisdom - Weekly Tips

Need More Details?

CONTACT US

Agilonomics/Palo Alto
customer.support@agilonomics.com

Copyright © 2025 Agilonomics.com.
All rights reserved

Linkedin Facebook Instagram Reddit Youtube

Transform Your Team, Elevate Your Business!

Subscribe to the Agilonomics Newsletter and Claim Your Free Power Team Consultation Today!

We promise to keep your email address safe. You can check our Privacy Policy.

Thank you for subscribing to our Agile Wisdome - Weekly Tips!

You’re almost there! Please check your email and click the confirmation link to complete your subscription. If you don’t see the email, be sure to check your spam folder.

Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognizing you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.

Strictly Necessary Cookies

Strictly necessary cookies are enabled at all times so that our website can function optimally.

3rd Party Cookies

Our website uses Google Analytics to collect useful information. These cookies are used by us to build a profile of interest and show you relevant offers.

Keeping these cookies enabled helps us to improve our website and your experience.