The Product Backlog: Your Secret Recipe for Bringing Products to Life!

If you were a chef in a busy kitchen, then the pages in your favorite recipe binder could be your Product Backlog. You would not consider this binder to be merely a list of ingredients, right? But more like a prioritized collection of culinary wonders waiting to be cooked up into a delicious masterpiece! So, exactly as a recipe guides you step by step, the Product Backlog steers you towards creating a delightful product. It’s a collection of ideas, features and improvements, all carefully prioritized to make sure you’re working to create the most valuable experiences to your customers. A powerful thought to deep dive on: Is your Product Backlog coming up like a well curated menu, or is it more like a disorganized kitchen drawer stuffed with arbitrary ingredients? Prioritization is the secret dressing! In the same way as an expert chef would skillfully select the finest ingredients for a dish, you need to prioritize the Product Backlog Items (PBIs) that bring the most value to your customers, users and business. This is as kin to finding that perfect balance of flavor and value! Ready for the final gem? Roman Pichler, one of the Agile Product Management Gurus’ wise words echo loud and clear: “The Product Backlog is a prioritized list of work remaining that is necessary to bring the product to life.” To all the Scrum Masters, Product Owners and Agile enthusiasts, I urge you discover the true power of the Product Backlog by embracing the art of prioritization. Craft a delectable menu that delights your customers, and watch as your products come to life in the most amazing way! ✨ Adapted from Agilonomics’ LLC LinkedIn post (June 2023)

Risk: Barrier or Gateway to Opportunity?

Risk: Obstacle or Opportunity?

Do you view risks as just obstacles? Here’s why you should be seeing them as opportunities In product development, risks are often seen as just another obstacle to overcome. But what if you could turn each high-risk item in your project into a potential opportunity? That’s where the concept of “driving a bus through a wide-open window” comes in Each high-risk element is like a bus that needs to be driven through an open window of opportunity. The bigger the bus, the bigger the window needs to be   To make risks work for you, it’s crucial to tackle the biggest risks early on. During the earliest stages of development, the window of opportunity is wide open, making it easier to drive the big buses through    But as each day passes, the window closes a little more, and if you don’t find the big buses in your project early, you’ll end up with a disaster at the end, as the metaphorical bus crashes into the nearly closed window   That’s why it’s so important to focus on the highest-risk elements from the very beginning, building them early and validating them with each sprint By doing this, you can turn risks into opportunities and achieve potentially shippable software with each iteration So, what are the big buses in your project? How can you drive them through the window of opportunity before it’s too late? Remember: The earlier you address the biggest risks, the better the chance of succeeding with your best ideas As each sprint goes by, your window of opportunity becomes smaller and smaller By driving the big buses through early on, you can turn risks into opportunities and achieve success in your product development journey. (Taken from Amit’s Linkedin Post last April 21, 2023)

Agile vs Waterfall: Methodology Comparison By Agilonomics

Agilized Waterfall vs Agile

Scrum Masters, Agile Coaches and Scrum Teams will find it useful to download and place it near their team workspace – either on digital (Miro, Mural etc.) or print and tape it on a physical wall (in office)     When working hard to quickly create stories and work items without understanding the big picture, we tend to take the Agilized Waterfall route (see top half of image), which results in: → Components that do not provide much value → They do not fit together when all done separately/sequentially → This leads to rework towards the end → Results in Frankenstein products – whose parts do not fit well → Iterative and incremental – Agile values not quite understood   (All this is represented in the top part of the image – Agilized Waterfall)   The bottom part (Agile) shows: → Early Sprints should show the shape and form of the whole product or feature → Quick prototyping means a rough version to get feedback on the shape and form → Subsequent Sprints provide a revised version of the product/feature which is now being built to quality → True value of what Agile Iterative and Incremental promised → Every stage is (potentially) usable   This visual artifact helps create awareness on what Agile promises if followed wisely and helps challenge a Scrum Team on effective ways to groom and create stories for higher value delivery   Hope you and your teams find it useful! 😊 (Note: Early versions of this artifact were all hand drawn on whiteboards, but now I have created a digital one so it can be used easily)   (taken from Amit’s Linkedin post “January 20, 2023”)

Optimizing Workforce Efficiency: Employee Utilization with Agilonomics

Effective “Utilization” of Employees

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”)

Crafting Effective User Stories: Understand Expert Advice With Agilonomics

A tip on creating good user stories

Experiment and Believe! So many times while using Agile, we get convinced with popular notions only to find that they don’t provide much value. Perhaps the people who made those notions popular were meaning something else? It happened to me years ago! One such notion I believed for years was, that, if it’s a small story, it’s a good story! I broke down work and large stories (without much thought), into smaller ones so they can fit in the Sprint. My teams worked on them, finished quite a few of them as well and we cherished the burndowns, predictability and velocity   See also; Tackling Unfinished Stories at the end of a Sprint   Then, one day I met Jeff Patton, who asked me [JP] Amit, I see you’re doing great work finishing so many stories. But, how is your team providing value? [Me] Value??, what do you mean? We deliver lots of points every Sprint, have high predictability and look at the nearly perfect burndown charts [JP] Amit, but this does not prove you are delivering high value [Me] Confused? What do you mean? [JP] Let me show you (JP Takes out a $1 bill, rips it into several pieces and hands me approximately 1/4th random pieces of the ripped bill) [JP] Now, tell me. Is that Twenty Five cents (1/4th of $1)? [Amit] Well, er…. No! [JP] Do you see, just breaking work into smaller stories to fit a Sprint isn’t providing value [Amit] Yeah, makes sense [JP] What would be a better approach? [Amit] I got it. I took out loose change. A couple of quarters, few – pennies, dimes and nickels – adding up to $1 [JP with a smile] Exactly. There’s always a way to look at work and breaking it into ways that provide value. If not each, then a few of them should be valuable     Since that time, I learnt to experiment and believe The INVEST acronym for good user stories goes this way: I = Independent N = Negotiable V = Valuable E = Estimable S = Small ??? T = Testable Mike Cohn has also redefined “S” from being “small” to “succinctly small” , which means “brief and clearly expressed” and I believe “clearly expressed” has to do with “valuable” What experiments have you done on busting Agile myths and finding out deeper meaning behind popular notions? What have you learnt from them?

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.