Search Results

This customer story was originally published on March 19, 2021. We asked Ben Parry, Partner & Integration Delivery Lead at John Lewis, about his mission to reduce integration delivery lead time by 25% and how the improved metrics and reporting from ActionableAgile Analytics help make that possible. Here’s what he had to say! ActionableAgile Analytics connects my team more to outcomes and helps us to respond to trends over time. Outside my team, it’s now possible to have a common language around charts and metrics. The scope for cross-team learning is increasing. What was going on in your business that made you look for flow metrics and then eventually purchase ActionableAgile Analytics? The last five years have seen rapid growth in both our food and GM websites. Do more with less! Be disruptive! Be efficient! This push brought a focus on flow, and many people have been introduced to ActionableAgile Analytics to visualize it. I became involved as I was aware of the opportunity to act on insight from data in non-digital contexts. I believed that waiting time could be reduced/eliminated on one of the strategic projects that I was involved with. I wondered if planning could be driven more by data; one big project was reissuing plans every six weeks - was there a lighter-weight way to forecast delivery? I’d taken customer feedback that a ‘consistent sense of urgency’ would be appreciated - there seemed to be months in refinement but days for build. Soon after, I started a Lean Six Sigma Green Belt project to see if I could improve my team’s delivery. There were suspicions we were slow; could we become more efficient? To track progress over time, I invested time in getting the most from ActionableAgile Analytics. What did success look like for you at that time? Success was making waste visible and having better conversations on how to reduce them. We needed to work out which wastes were worth tackling first. I used ActionableAgile Analytics and SigmaXL to look at trends in queuing and activity cycle times. The initial goal was to concentrate on a key metric and increase awareness of that within my team. This was lead time - a customer outcome, not an activity output. The second was to communicate this upwards to my sponsor, which helped me complete my Green Belt Project. How has ActionableAgile helped to achieve that success? My approach has definitely evolved over time. I’m having better conversations about aging work. I intervene on the top ten oldest tickets or the oldest in a status. Last year, I could also justify recruitment decisions based on the arrival and departure rates on Cumulative Flow Diagrams (CFDs). Which features or benefits do you like best about ActionableAgile Analytics? Speed. The time between loading a board from JIRA and inspecting the related CFD is less than 5 minutes. There is no data refinement required - data is simply pulled from JIRA. I like zooming into a CFD and hiding statuses, etc. - something I can’t do with the native Jira CFD. ActionableAgile Analytics is great for detective work! What was the most valuable thing using ActionableAgile Analytics has brought, and why? My team is now more connected to outcomes (lead time to deliver value to system test) and our delivery trends over time. Outside my team, it’s now possible to have a common language around charts and metrics. The scope for cross-team learning is increasing. What results (qualitative or quantitative) have you seen because of using ActionableAgile Analytics? I’ve inspected how the digital agile teams manage flow and conducted an experiment to see what I could make of their data blindfolded. In doing that, I developed a repeatable process where I could build a report to look at WIP, lead time, throughput, and age in 90 minutes and then playback to the team in 30 mins. Reception to this has been positive, and I’ve had good conversations understanding why my perception of work through data may differ from the reality on the ground. E.g., a dip in throughput - “Yes, that’s where we lost a developer!” I champion the use of flow metrics and ActionableAgile Analytics as lead of our Flow Optimisation Community (>100 members). What’s next in your journey? I’m keen to look at flow beyond and within individual teams, perhaps tracking Epics across teams. At the organisation level, I’ve also been consulted on both: whether we have the right mix of work (Feature v Compliance work) as well as how to get a consistent way to train on metrics so Partners can ‘self-serve’. The worsening economy makes the hunt for waste increasingly urgent. It’s great to have the insight from ActionableAgile Analytics in my back pocket.

We're excited to announce that 55 Degrees will again join the vibrant Atlassian community at Atlassian Team’24, happening in Las Vegas from April 30th to May 3. Team '24 is a fantastic event that brings together the Atlassian community, providing a platform to connect, collaborate, and drive advancements in how people work together, leveraging deeper human insights and breakthrough technology. At 55 Degrees, we create innovative apps to help you understand your workflows and streamline your work experience. Atlassian Team'24 is the perfect platform for us to connect with the Atlassian community and explore the future of teamwork alongside inspiring minds. What to expect when you visit our booth Get ready for a jam-packed experience at our booth! We've got something for everyone: Products Conversation: Dive into a conversation with our team about our apps and how they can transform your work. Discover how to streamline your workflow and enhance productivity with our tailored solutions. Swag Giveaways: Be sure to snag some 55 Degrees swag, including t-shirts, sleep masks, and the coolest stickers you've ever seen – each representing a member of our team. You won't find these stickers anywhere else! Rock Paper Scissors Competition: Join the excitement of the biggest competition at Team’24 – our rock paper scissors tournament! Compete against fellow attendees for a chance to win a surprise gift and bragging rights. Special Guest Appearance: We're thrilled to announce that Author and Agile Coach Daniel Vacanti will join us at our booth. Get ready to dive deep into discussions about agile methodologies, predictability, and the transformative power of ActionableAgile for businesses and work cultures. Don't miss this opportunity to gain valuable insights from an industry expert! Introducing our Team Our amazing team will be at the booth, ready to chat, answer your product-related questions, and connect with you. For Atlassian Solution Partners, Our Partner Success Manager will be there to discuss your specific needs, and of course, we'll have plenty of those epic stickers to share. We can't wait to connect with fellow Atlassian enthusiasts, share our passion for enhancing work experiences, and explore how we can collaborate to drive advancements in how people work together. Stop by Booth #12 at Atlassian Team’24 – we'll see you there!

This article is a guest contribution from José Coignard, ActionableAgile customer, Professional Kanban Trainer, and Agile Coach in Europe’s largest financial institution. It was originally posted on his blog. Jump down to read more about José. Story points, c'est quoi? Un peu d'historique... Ce concept largement répandu et très mal répandu (à mon plus grand désarroi, vous le comprendrez si vous allez au bout de cet article) a été initialement créé par Ron Jeffries au sein de l'extreme programming (XP). Story points (ou points d'effort, de complexité en français) est une estimation relative d'un élément de travail. Le concept englobe des notions d'effort, de complexité, de temps, de risques, de niveau de compétences, de nombre de café requis pour terminer le sujet (oups je dérive...), etc. A la base c'était une estimation en temps pour implémenter une histoire utilisateur (les éléments qui étaient à connotation de valeurs pour un utilisateur final dans XP). Ron a rapidement décrit cela comme le temps idéal pour compléter une histoire à 2 personnes en pair programming, si le monde autour d'eux voulait bien leur ficher la paix. Seulement ce n'était jamais le cas et il y avait des risques, de la complexité cachée, etc. Il a donc introduit un facteur multiplicateur à cela (dans son expérience, c'était aux alentours de 3). Ce qui a fini par lui faire transformer cette estimation en temps idéal en une notion de points car les parties prenantes ne comprenaient pas qu'une journée idéale de travail puisse se transformer finalement en 3 jours réels. (Merci les parties prenantes qui ne comprennent pas que dans ce monde de travail intellectuel, on ne peut pas voir les choses de façon déterministe... Et que c'est un véritable danger de le faire!) Bref fin de la parenthèse, revenons à nos moutons... L'idée et l'utilisation de Ron (et de sa team à l'époque) de ces story points étaient tout simplement d'avoir des discussions au sein de l'équipe et de pouvoir juger si l'équipe était en train de ce challenger sur quelque chose de faisable ou pas sur l'itération. Donc Ron transforme cette notion en point... en story points! ("Nants ingonyama bagithi baba" ... Sur un célèbre air... Le lion est né!). Et c'est la que le drame commence. Quel drame? Que s'est-il passé? Sérieusement?! Vous osez me poser la question? Bon allez parce que c'est vous, je vous explique... Un célèbre framework apparaît et prend de plus en plus d'ampleur sur le marché: Scrum.  Il faut dire que le framework est plutôt séduisant et vient avec des potentiels bénéfices intéressants (que beaucoup prendront à mon sens comme des promesses). Pour une raison propre à l'être humain toujours très inventif, des pratiquants de Scrum commencent à utiliser les story points de Ron. Sauf que... l'utilisation de ces story points commencent à dévier de l'utilité initiale. Des personnes commencent à les utiliser pour faire des projections et des plannings au-delà d'une itération, pour comparer la performance de plusieurs équipes, pour pressuriser les équipes à toujours faire plus de story points par itération (cette fameuse vélocité)... Tenez, arrêtons-nous sur ce dernier point. Est-ce que dans la notion de story points de Ron, il y a une quelconque notion de valeur pour l'utilisateur final, pour le business? Bingo! Vous avez raison... AUCUNE! Alors pourquoi donc des managers, des parties prenantes, logiquement intéressés par le fait que le business se porte bien et de mieux en mieux, viendraient mettre la pression aux équipes pour qu'elles augmentent leur vélocité?! Alors? Alors? Oui j'entends timidement la réponse au fond de la salle... "Parce qu'ils n'ont rien compris à ce que c'était ! Et pensent que plus de vélocité = plus de valeur" Merci! Ça m'évite de le dire! Malheureusement, ce non-sens se propage, c'est une maladie hautement contagieuse et virale... Le monde est pris dans cette pandémie d'utilisation des story points, à mille lieux de l'idée originelle de Ron et de l'utilité qui l'avait amené à créer cela. Le pauvre... Car malheureusement, il est bien identifié comme le créateur des story points. Il en fera d'ailleurs un mea-culpa, que je vous donne ici en français: "J'aime dire que j'ai probablement été l'inventeur des story points, et si je l'ai fait, j'en suis désolé maintenant." Bon, bah, c'est bien beau tout ça, mais comment sortir de cela? Je suis content que vous posiez la question. Donc, ce que vous voulez savoir, c'est si vous ne vous challengez pas trop sur une itération, avec un objectif inatteignable avant même d'avoir démarré. De plus potentiellement avec une communication hasardeuse auprès de parties prenantes, qui prendront cet objectif comme une promesse à la fin de l'itération et qui vous attendront de pied ferme si vous ne l'honorez pas. Bonne nouvelle, c'est possible et sans les story points ! Et je dirai même que j'ai mieux et plus prédictible que ce que vous pouviez avoir avec des story points (sous certaines conditions). Bon soyons honnête, ce que je vous donne après ce n'est pas moi qui l'ai inventé, mais les personnes qui sont derrière la stratégie Kanban (la vraie) comme Daniel S. Vacanti par exemple (Mais comme je sais qu'il tient beaucoup à rendre hommage aux personnes qui étaient avec lui, je vous donne ma traduction de son bouquin où il raconte l'histoire et rend cet hommage : https://drive.google.com/file/d/1QJu4FQdBG1iFwzn4H4wTtPT0DuMPfweM/view?usp=sharing) Par contre, j'ai pas mal utilisé cela, dans différentes équipes et je peux vous assurer que ça fonctionne très, très bien ! (et je ne suis pas le seul à le confirmer). C'est parti et je vais essayer de vous synthétiser cela en moins de 200 pages... Ce que vous voulez, c'est une estimation plutôt fiable, la plus fiable possible, quand bien même nous soyons dans un monde d'incertitude. Pouvons-nous faire ces 10 items correspondants à notre objectif, ou seulement 8, ou plutôt 15 ? Et puis aussi on le verra un peu plus tard, afin de communiquer, répondre à des questions du type "Quand est-ce que vous pensez pouvoir compléter cette version?" Et si vous comptiez simplement le nombre d'éléments? D'histoires? Et si vous regardiez historiquement ce que vous avez réussi à faire? Bah non, ça ne marchera pas, les éléments ne sont pas de la même taille! Exactement! on a des sujets plus gros que d'autres et c'est bien pour ça qu'on estime en story points! Oki ... Oki... Calmez-vous ! Laissez-moi compléter... Je ne suis pas complètement en désaccord avec vous. Mais! Pensez-vous que vos estimations en story point soient justes? Bah oui, quand même, on est rodé! Attends, c'est vrai qu' "estimation"... Le mot en lui-même comporte une part de doute, une estimation peut-être fausse. Oui, exactement! Je dirai même que vous devez partir du principe qu'elle est fausse (bon parfois, mais plutôt rarement, vous tomberez juste.) Pourquoi? Parce que vous n'êtes pas dans un monde déterministe. Tenez! À quand remonte votre dernière découverte de quelque chose que vous n'aviez pas imaginé vous tomber dessus en réalisant une story? Je parierai que ça fait 1 jour, pas plus! C'est normal... Dès que vous allez commencer le travail sur le sujet, vous allez obtenir des informations qui vous feront entrer dans la réalité, la vraie réalité des choses et puis potentiellement, il y aura un changement intéressant à mettre en œuvre pour mieux satisfaire l'utilisateur. Il va se passer tout un tas de choses imprévues, vous allez avoir l'univers contre vous pour que ça ne se passe pas comme vous l'imaginiez. Ouais, bon d'accord, ce n'est pas faux! Vous n'avez pas compris quelque chose? (Désolé pour les non-fans de Kamelot ;-)) Donc, comment faire en ne comptant que les éléments, qui ne font pas la même "taille"? Alors, ils doivent faire, non pas la même taille, mais la bonne taille. J'entends par là que vous devez convenir en équipe d'une taille, en nombre de jours (ça servira pour autre chose d'être dans cette unité.), qui sera un point de comparaison et un point limite pour les éléments que vous allez travailler. Pour être vraiment dans l'idée de voir les choses de façon non-déterministe (si si c'est important et donc je vais le dire 1000 fois dans l'article), vous allez associer à cette timebox une probabilité de rester dedans (ou si vous voulez le voir dans l'autre sens une probabilité de la dépasser). Ça donne par exemple : "Taille de nos éléments de pas plus de 10 jours à 85% du temps". Dans la stratégie Kanban c'est ce qu'on appelle le niveau de service attendu (SLE). Avec ce SLE vous allez donc pouvoir définir vos éléments avec une bonne taille, ie une taille qui entre dans ce SLE. Attention, le sujet n'est pas de tomber juste, juste. C'est "pas plus de" 10 jours... Une timebox... Si c'est fini avant. Top ! Des utilisateurs pourront potentiellement bénéficier de quelque chose qui leur sera utile plus tôt. Donc au lieu de faire des estimations en story points, points d'effort ou complexité comme on les a renommés en France via des techniques de planning poker sur suite de Fibonnacci ou autre unité aidant à la relativité de l'estimation... Vous allez jouer à un planning poker un poil transformé, avec seulement 4 cartes : - 1 carte, j'en sais fichtre rien! - 1 carte, rentre assurément dans notre SLE - 1 carte, pas moyen que ça tienne dans le SLE - 1 carte, je n'ai pas compris le sujet, on peut réexpliquer? Voici différents scénarii possibles : Plein de "j'en sais fichtre rien!"... Il faut alors très certainement rediscuter pour mieux comprendre ce qu'il en retourne... Et au bout d'un moment si ça ne s'éclaircit pas par les discussions, il faut se lancer et faire. Le seul moyen de savoir concrètement si c'est dur ou pas et si ça dépassera le SLE ou pas. Plein de "je n'ai pas compris le sujet, on peut réexpliquer?" Idem, il faut rediscuter, éclaircir... Et potentiellement se lancer. "C'est en marchant qu'on apprend à marcher !" Que des "rentre assurément dans notre SLE", bon bah allez passons au sujet suivant Pas mal ou plein de "pas moyen que ça tienne dans le SLE"... Il faut rediscuter et trouver des moyens de découper le sujet pour arriver à sortir l'élément le plus important qui entre dans le SLE et remettre le reste à des discussions futures. (ou immédiates si c'est très important pour aussi s'assurer que ça entre dans le SLE) Un mixte de tout ça... Il faut rediscuter, tout le monde n'a pas compris la même chose, il y a peut-être des idées intéressantes de découpage, etc. Oki! Une fois que circulent dans notre workflow et que se réalisent dans nos itérations des éléments de bonne taille, on va pouvoir prendre le débit (nombre d'éléments qui se terminent par jour) et utiliser cela pour faire une projection probabiliste de ce qu'il est possible de faire dans une itération (dans la timebox de l'itération). Un excellent moyen de faire cette projection probabiliste et d'utiliser une simulation de Monte-Carlo en prenant en entrée ce débit par jour. Ceci vous donnera quelque chose de beaucoup plus précis que ce que vous faisiez avant et en plus un choix de voir ce que ça donne avec 50% de probabilités, 70%, 85%, 95%... Quel niveau de risque êtes-vous prêt à prendre? Ça sera aussi des discussions que vous pourrez avoir avec cette démarche. Exemple de simulation de Monte-Carlo ci-dessous : Sur cet exemple, il y a 85% de chances que l'équipe arrive à réaliser 6 éléments ou plus dans l'itération à venir (de 3 semaines), 7 ou plus à 70% de chance, 4 ou plus à 95% de chances. Un autre avantage de cette démarche, c'est de pouvoir donner une meilleure réponse à "Quand cela sera-t-il terminé?" Avez-vous déjà réussi à tomber juste dans votre prédiction de date de release en vous basant sur les story points (ou la vélocité)? Si c'est le cas, bravo ! Vous devriez jouer au loto ;-) Je présume, en étant sûr de ne pas me tromper, que comme moi, vous n'avez jamais vu cela ou par miracle une fois et pas beaucoup plus. Attention, quand je dis ça, c'est bien évidemment en étant honnête et sans avoir trituré le périmètre, ou bafoué la qualité ou les deux, pour faire entrer absolument la release à la date convenue et communiquée. Eh bien, vous savez pourquoi? Parce qu'il n'y aucune corrélation entre les story points et la durée que vous allez prendre pour terminer les éléments. Enfin aucune corrélation... un degré de corrélation très, très faible (0,2 ... 0,3 allez max 0,4). Donc est-ce que cela fait sens de réaliser des projections sur des dates, sur la base de story points, qui ont une corrélation très faible avec la durée que ces éléments prennent en réalité pour être réalisés? Pas vraiment, ou même aucunement! Tenez c'est cadeau, un exemple de non-lien entre story points et temps de cycle (durée pour qu'un élément traverse le workflow). Exemple réel, le même schéma s'est présenté plus d'une dizaine de fois à moi. Un collègue ProKanban Trainer a fait l'exercice sur plus de 100 équipes, toujours pareil... Et toujours avez un taux de corrélation ne dépassant pas les 0,4 et plutôt autour de 0,2. Ce graphique vous présente en axe X (horizontal) l'estimation en story points, en axe Y (vertical) le temps de cycle pour terminer l'élément. Vous voyez donc que des éléments avec beaucoup de points se terminent bien plus rapidement que d'autres avec moins de points estimés. Inversement, des éléments avec peu de points estimés se terminent bien moins rapidement que des éléments avec beaucoup de points estimés. Réponse à la question concernant un seul élément Si la question ne porte que sur un seul élément, alors dépendant de là où se trouve l'élément dans le flux de travail, vous pourrez répondre grâce à votre temps de cycle historique. Exemple : L'élément n'est pas encore démarré. Votre temps de cycle historique est de 12 jours ou moins pour 85% des éléments. Vous pourriez alors répondre "si nous démarrons aujourd'hui vous avez 85% de chances que nous fournissions cet élément dans les 12 jours à venir" (Au fait, je parle en jour calendaire... Pourquoi ? Ça fera certainement l'objet d'un autre article) Exemple 2 : L'élément est démarré. Le workflow est "Affinage > Dev > Recette > Terminé" et l'élément est dans l'état "Dev" avec un âge dans le flux de 5 jours (ie il a déjà passé 5 jours entre "affinage" et "dev"). Vous pourriez alors répondre "nous avons déjà travaillé 5 jours sur le sujet, il y a maintenant moins de 85% de chances que nous finissions dans les 7 jours suivants" (Oui, car la probabilité de finir un élément déjà démarré dans la timebox du SLE décroît dès le premier jour... Ça fera certainement également l'objet d'un autre article pour entrer dans ce détail, pour le moment sachez juste que c'est moins de 85% de chances en simplifiant les choses). Réponse à la question concernant plusieurs éléments (pour une release par exemple) Dans le cas où la projection probabiliste porterait sur plusieurs éléments, il faudra prendre le débit en élément par jour pour pouvoir répondre. En réalité, c'est la même technique que pour vous lorsque vous regardez combien d'éléments, vous pouvez prendre dans votre itération, juste qu'au lieu de le voir en nombre d'éléments dans une timebox donnée, on regarde où nous emmène le fait de faire un certain nombre d'éléments. Donc débit journalier et simulation de Monte-Carlo. Attention à bien prendre la bonne période pour le débit historique. Vous devez prendre une période de débit historique qui corresponde (à priori) au mieux à l'avenir que vous projetez. Enfin, n'hésitez pas dans la réponse à la question de proposer plusieurs niveaux de risque. Vous pourriez très bien répondre : "Nous avons 70% de chances de terminer cette release pour le 15 février, 85% de terminer le 24 février et 95% de terminer le 1er mars". Cela plaira à votre interlocuteur sans aucun doute et vous pourrez convenir du niveau de risque acceptable pour lui et ainsi continuer à monitorer cette projection dès lors que vous avez de nouvelles données de débit historique. Avec la simulation de Monte-Carlo ci-dessus, pour une release comportant 40 éléments à compléter la simulation nous donne : 70% de chances de compléter cela pour le 2 Mai 2024, 85% de chance pour le 13 Mai 2024, 95% de chance pour le 21 Mai 2024. Comment convaincre de lâcher les story points et de basculer en principe de bonne taille? Je dirai avec mon expérience qu'il n'y a pas de recette miracle. Mais une qui a souvent fonctionné pour moi est de montrer la différence entre les deux approches de projections (même sans être dans une logique de bonne taille). Vous avez certainement déjà une ou plusieurs release historique. Vous connaissez donc factuellement votre date de livraison. Regardez ce que vous aviez prédit avec une projection par la vélocité (Et encore une fois, soyez honnête, prenez la première projection là où vous n'aviez pas encore trituré le périmètre, la qualité... Pour faire entrer la release au chausse pieds à la date voulue). Maintenant, prenez le débit historique par jour des éléments, faites une simulation de Monte-Carlo avec cet historique en vous remettant à la date de démarrage et avec le nombre d'éléments que vous aviez imaginé au début de cette release. Je mettrai ma main au feu, que vous avez un meilleur résultat, plus proche de la réalité avec la simulation de Monte-Carlo. Et attention, c'était sans faire une approche de bonne taille pour vos éléments. Vous allez augmenter la prédictibilité en faisant cela et en vous tenant à contrôler l'âge de vos éléments dans votre flux par rapport à ce SLE que vous choisirez. Conclusion Bon eh bien, ça n'aura pas fait un bouquin de 200 pages, mais un bien long article quand même. Si vous êtes arrivés jusque-là (en ayant tout lu), bravo! J'espère que cela vous aidera à mettre de côté les story points ou, en tout cas, la très mauvaise utilisation que beaucoup (trop) de monde en font. Je vous invite, vraiment et très sérieusement, à vous pencher sur la stratégie Kanban dans sa globalité si vous voulez vraiment réussir à vous passer des story points et avoir tous les bénéfices de cette stratégie pour optimiser votre efficacité, votre efficience et votre prédictibilité. Si vous mettez en place uniquement ce que j'ai décrit dans cet article, vous obtiendrez certainement des résultats intéressants, mais vous aurez moins de chances que cela se produise que si vous mettez en place les 3 pratiques clés Kanban appuyées des 4 métriques de flux essentiels. En tous cas, vous allez être limité à un moment sur le niveau de prédictibilité que vous allez pouvoir atteindre. Donc si vous voulez creuser tout cela, je ne peux que vous recommander de venir avec moi en formation sur la stratégie Kanban, de lire mes autres articles, de me suivre sur LinkedIn (https://www.linkedin.com/in/jose-coignard/) , de lire les ressources gratuites qui se trouvent sur https://prokanban.org, de venir vous abonner au Slack de ProKanban.org https://join.slack.com/t/prokanban/shared_invite/zt-2a4ofpd9g-7PvTd5RiV5h17tCmUdVxuA Sources : L'histoire des story points racontée par Ron lui même : https://ronjeffries.com/articles/019-01ff/story-points/Index.html About José Coignard, Guest Writer José Coignard is a French Professional Kanban Trainer and Agile Coach in Europe’s largest financial institution. As a user and advocate of ActionableAgile Analytics, he is pursuing a quest to acculturate and develop the Kanban strategy in his company and beyond for French and French-speaking people.

At the heart of Malmö, Sweden, where innovation meets inspiration, 55 Degrees once again took center stage at the Øredev Developer Conference from November 8th to 10th, 2023. As a testament to our commitment to revolutionizing team workflows, our booth became a hub of meaningful conversations, exciting giveaways, and friendly competitions. Let’s take a journey through the highlights of this extraordinary event. Empowering Workflows Through Conversations Our booth became the focal point for participants seeking revolutionary solutions to elevate their organizational workflows. With passion, our team conveyed how our software products can boost collaboration and productivity for teams and organizations. The exchange of ideas and experiences ignited a shared enthusiasm for innovation. To inject some fun into our workflow discussions, we set up a fortune wheel at our booth. Attendees spun the wheel, and the excitement was contagious! Lucky participants won cool swag like beanies, baseball caps, backpacks, and exclusive tickets to our highly anticipated rock-paper-scissors competition the next day. Team Spirit in Stickers: Putting Faces to 55 Degrees To make personal connections at the conference, we shared stickers representing each member of the 55 Degrees team. It was heartwarming to see the joy on everyone’s faces as they collected these tokens of team spirit. Connecting faces to our brand resonated deeply with our commitment to building genuine customer relationships. Rock, Paper, Scissors: A Grand Finale to Remember The pinnacle of our participation unfolded the next day with the Rock, Paper, Scissors competition. The crowd gathered, anticipation filling the air, as attendees battled for the grand prize—an Airpods Pro. This spirited competition highlighted 55 Degrees’s dedication to building a lively community and served as a memorable and entertaining conclusion to the conference. This year marked our second appearance at the Øredev Developer Conference, and it was undeniably one of our favorite moments of the year. The connections forged, the excitement shared, and the lessons learned are invaluable to our ongoing journey. To everyone who stopped by our booth, engaged in conversations, spun the fortune wheel, collected stickers, and participated in the rock paper scissors showdown, thank you! Your enthusiasm and energy fueled the success of our journey at Øredev 2023. Until next year, thank you for the memories! Capturing the moments that sparked meaningful conversations, exciting giveaways, and friendly competitions.

What is SOC 2, and why is it important? SOC 2, or Service Organization Controls 2, is a framework governed by the American Institute of Certified Public Accountants (AICPA). With a SOC 2 audit, an independent service auditor will review an organization’s policies, procedures, and evidence to determine if their controls are designed and operating effectively. A SOC 2 report communicates a company’s commitment to data security and the protection of customer information. Improving your security posture SOC 2 compliance exemplifies an organization’s commitment to customer trust and is a major milestone toward improving their overall security posture. With increasing cybersecurity threats and data breaches, it is paramount that organizations prioritize information security and the protection of their systems and data. By undergoing a SOC 2 audit, our controls and processes were validated by a third party who attests to the functioning of the controls relevant to our application. Why we pursued SOC 2 now? At 55 Degrees, two of our company values are "Make things better" and "Put people first." An important part of living up to those values is our commitment to data privacy and security throughout all aspects of our organization. From recruiting and training to onboarding new tools to delivering new products and features, we don’t take a single step without ensuring we’ve taken all reasonable steps to protect your data and your privacy. SOC 2 compliance is integral in proving to customers, stakeholders, and interested parties that our organization lives up to those values and has effectively implemented security controls. At our company’s stage, we realized that it was an ideal time to pursue this as it is important to protect data and mitigate potential security risks early and on an ongoing basis. 55 Degrees’ journey to SOC 2 compliance Compliance Partners Without the right compliance partners to guide us on our journey, the task would have seemed insurmountable. There were some key partners involved in our SOC 2 compliance journey. We partnered with Vanta to help us automate the collection of our audit evidence and monitor our continued compliance. Vanta provides us with the strongest security foundation to protect our customer data. Our audit firm, Advantage Partners, was extremely helpful in creating a seamless audit experience. With their guidance and support, we were able to achieve SOC 2 compliance in a swift, efficient manner. Process While SOC 2 can be a big undertaking, our compliance partners streamlined the process. We leveraged Vanta to integrate our key systems and guide us in quickly implementing policies and procedures to become audit-ready. Vanta gave us the direction we needed to pursue our compliance journey in a much shorter timeline than we would have had without them. Advantage Partners then confirmed our audit readiness, and we kicked off our Type II audit. Advantage evaluated the controls we have in place for the audit and opined on their state. In a matter of weeks, after our audit window ended, Advantage Partners drafted and issued our report. Timeline One key takeaway is understanding that improving our security posture and achieving compliance is a monumental task. This can be made easier with the right compliance partners, but it will take dedicated focus and time from your organization. The readiness period can take the most time, but we were able to make compliance a priority to get audit-ready in just a couple of months. We also found it important to review the audit timeline with Advantage Partners, set an ideal audit date, and work backward to be ready in time. We started with the required 3-month audit window. However, now that controls are implemented, we plan to exhibit our focus and priority on security by maintaining audit readiness at all times so that subsequent SOC 2 audits will be even more seamless and cover longer audit periods. Lessons we learned Start the process early. It is easier to implement policies earlier rather than later, and doing so as early as possible helps you build a more secure organization from the start. Building secure procedures and infrastructure are key components of a successful security program. Focus on improving security posture, not checking boxes. Compliance is not one size fits all. Ensure you are spending time understanding the frameworks you’re working towards so you can know how to best comply for your organization. Your entire organization will be involved in improving security and adhering to procedures. Help them to understand how they impact your ability to stay compliant! Security is a continuous project that should be prioritized in an organization. Don’t snooze your alerts - aim to stay at 100% readiness in Vanta all the time! The right partners and tools are key. Finding a compliance management tool like Vanta to guide you through the process makes it so much easier to know what to do and to do it quickly. Not only does it make it easier to get started, but it makes it (nearly) painless to maintain your audit readiness! For us, leveling up our licenses in tools like Snyk Enterprise has really taken the pain out of managing certain aspects of our compliance and providing the necessary proof. Finally, partnering with an audit firm dedicated to your success makes the process much less scary! Make sure you find a firm that you feel comfortable with and that is comfortable in your compliance management system. You can read more about our trust stance at https://55degrees.se/trust. If you would like to request access to our SOC 2 report or see information about the controls currently in place and other publicly available documents, you can visit our Vanta Trust Center at https://trust.55degrees.se. If you have any other questions, please contact us!

In today’s rapidly evolving tech landscape, where Software as a Service (SaaS) companies continuously strive for innovation and excellence, it’s crucial to remain mindful of our responsibility to both our communities and the world at large. At 55 Degrees, we firmly believe that true success extends beyond profits and market share. We take pride in our enduring commitment to making a positive impact and giving back to society. Our dedication to putting people first has been one of our core values since the beginning, and we are constantly seeking ways to make a difference through initiatives such as the “1% Pledge”, where we donate 1% of team member time to charitable causes and 1% of our profit. Supporting the Barncancerfonden One cause that has been close to our hearts is the fight against childhood cancer. The words "Children" and "cancer" should never coexist. As an organization, we proudly support the Barncancerfonden in their fight to keep cancer away from children. The Children’s Cancer Foundation fights childhood cancer and ensures that affected children and their families receive the care and support they need. As Barnsupporter 2023, we are involved and contribute to this noble cause. Despite advancements in medical science, the fight against childhood cancer continues. By donating to organizations like the Barncancerfonden, we are helping individual families and the collective effort to find better treatments and, ultimately, a cure for childhood cancer. Every day, a child in Sweden faces the harsh reality of cancer. However, there is hope! Thanks to research and more effective treatment methods, we’ve made significant progress, with 85 percent survival rate today. However, the ultimate goal is to ensure that every child diagnosed with cancer not only survives but also leads a healthy and fulfilling life. To achieve this, we proudly support Barncancerfonden by being a Child Supporter 2023. We encourage others to join us in supporting this vital cause, and together, we can bring hope and healing to children battling cancer. Do as we do, support Barncancerfonden | Stöd barncancerforskning Together, we help keep cancer away from children!

This article is a guest contribution from Julie Starling, ActionableAgile customer, and was originally posted on her blog. Jump down to read more about Julie. We're all familiar with Schrodinger's cat right? The cat in a box which has the state of both dead and alive whilst the box is closed … when the box is opened it is one or the other. I can't help but see the parallels to work items in our system. Schrodinger's Work Item An active item in our system represents both potential value and waste ...until we deliver it, we do not know which it is. Potentially Valuable – In most instances, we engage with our customers to understand what is valuable to them. Even in cases where direct customer communication is limited, we often hold a genuine belief in the value of what we're delivering. However, complete certainty about its value remains elusive until we actually deliver the item and receive feedback. Only when our work item is in the hands of our customers can we truly determine whether the time invested has indeed been valuable. Waste - Until we deliver the item, the time we are spending on it can also be considered waste, as until it's delivered there is always a risk it won't be delivered and the time spent up until now will have been for nothing… these situations happen all the time and can be for a number of reasons, be it a change in strategy due to a global pandemic or change of requirement from our customers and everything else in between. It can also have been waste if we deliver it an no one uses it, it doesn't deliver the expected outcome or if we don't get any valuable feedback. Let The Cat Out The Box Whilst we understand that work in our system is potentially not valuable, we shouldn't be using this as a reason to not be experimental with what we deliver! Instead, we should think about getting work items out of our system as efficiently as we can. This way we can find out if it was actually valuable as quickly as possible, learn from this answer and move on with this new knowledge. Compromising quality is also not the answer! Two ways to get the cat out of the box... 1. Don’t Start! If you haven’t started working on an item then you haven’t started potentially wasting time. You can then put your efforts on keeping work that has started active and flowing. 2. Finish It! If you’ve started...then finish! One way to get an item out of a system is to finish it. On their own they may seem like two obvious and probably unhelpful points. However if we look at the bigger picture, we shouldn’t start items until we know they have the best chance of flowing through our system. When we do start, we should be managing that work in progress always with a goal of finishing. We want to keep our work flowing and keep the work as busy and active as possible. If we start items before they can flow there can be a lot of sitting around in the system. The longer the item is in the system the possibility of the item being waste just increases as the world around us changes or items become stale. Don’t Put the Cat in The Box, But If You Do, Don’t Keep It In There Longer Than Necessary In essence we shouldn’t start work until it’s the right time for our system, and when we do start it, we should be managing the work in progress with the goal of finishing. There are a number of ways in which we can manage work in progress, including... 1. Limit the amount of Work In Progress By not having too much in our system we are able to focus on what is active, less context switching and spend our efforts on keeping our work busy (keep work busy before people). If you are in a situation where you have a team of busy people and a number of work items that aren’t actively being worked on, then you probably need to start controlling your WIP. 2. Make items small The smaller work items are the easier they are going to flow through your system. We need to make sure our items are right-sized and represent the smallest possible chunk of potential value. This will help flow but it will also help us get the necessary feedback we need to know if we need to pivot in the quest for value. With this approach if the world around us changes and what we were delivering is no longer relevant, we’ve also minimized the amount of waste. 3. Take action on items that are unnecessarily aging Any item that is staying in the system unnecessarily long needs action taken on it. This could range from splitting the work item down, resolving blockers or even kicking it out of the system! But how do we know if an item is unnecessarily aging? ...I’ll be covering that in my next post. Similar to the state of Schrodinger's Cat being unknown until perceived, our work items exist in a superposition of potential value and waste. That is, until they are delivered and observed by our customers. Actively managing the work in the system shortens the time to understand its fate! TLDR; We can’t assume all work will be as valuable as we expect when we decide to do it. Work not finished has a dual nature of both potentially valuable or waste until we deliver and get feedback. To get the answer to ‘was it valuable?’ as quickly as possible we should be focusing on flow. Keep items in our system for a short of a time as possible. Keep inactive time to a minimum. Whilst work is in our system, we should be actively managing it with a goal to getting it out (at a high quality) as soon as we can. Techniques such as managing WIP, right sizing items and taking action on aging items help us to do this. About Julie Starling, Guest Writer Julie is passionate about the efficient delivery of value to customers and avoiding the illusion of certainty. In recent years she has specialized in how data can be used to drive the right conversations to do this. She encourages teams to use data in actionable ways and adjust ways of working to maximize their potential. She has spent over 15 years working in and alongside software delivery teams. In her spare time, she loves to travel, snowboard, and is obsessed with houseplants!

It is inevitable that there are ways that the software creator intends a feature to be used and there are ways that it ends up being used. 🤓 Sometimes these unintended uses can be even better than the initial idea, but other times they can end up causing harm. In a recent chat with Daniel Vacanti, we discussed this very thing about ActionableAgile™️ Analytics. I can say I was more than mildly surprised when one of my favorite features came up: the pace percentile feature on ActionableAgile's Work Item Aging chart. I love this feature because it helps you get early signals of slow work. However, after talking to and training many people, Dan saw that people very often misinterpret what this particular signal really tells us. How did he come to that conclusion? He talked to them about the decisions they would make because of the signals and saw that they weren't necessarily picking up what was intended. Instead, the decisions people were likely to make could lead to even worse outcomes than currently presented on the chart. What do you think? Are you interpreting the signals correctly? Watch this short video from Dan to find out. As always, feel free to leave your (appropriate) comments and questions on our YouTube channel!

This is post 9 of 9 in our Little's Law series. I personally can't fathom how someone could call themselves a flow practitioner without a concerted effort to study Little's Law. However, the truth is that some of the posts in this series have gone into way more detail about LL than most people would ever need to practically know. Having said that, without an understanding of what makes Little's Law work, teams are making decisions every day that are in direct contravention of established mathematical facts (and paying the consequences). To that end, for those who want to learn more, here is my suggested reading list for anyone interested in learning more about Little's Law (in this particular order): 1. http://web.eng.ucsd.edu/~massimo/ECE158A/Handouts_files/Little.pdf Frank Vega and I call this "Little's Law Chapter 5" as it is a chapter taken from a textbook that Little contributed to. For me, this is hands down the best introduction to the law in its various forms. I am not lying when I say that I've read this paper 50 times (and probably closer to 100 times) and get something new from it with each sitting. 2. https://people.cs.umass.edu/~emery/classes/cmpsci691st/readings/OS/Littles-Law-50-Years-Later.pdf This is a paper Little wrote on the 50th anniversary of the law. It builds on the concepts of Chapter 5 and goes into more detail about the history of L=λW since its first publication in 1961. This paper, along with Chapter 5, should tell you 95% of what you need to know about LL. 3. http://fisherp.scripts.mit.edu/wordpress/wp-content/uploads/2015/11/ContentServer.pdf Speaking of the first publication of the proof of L=λW, there's no better teacher than going right to the source. This article would be my 3rd recommendation as it is a bit mathy, but its publication is one of the seminal moments in the history of queuing theory and any buff should be familiar with this proof. For extra credit: 4. http://www.columbia.edu/~ww2040/ReviewLlamW91.pdf This article is not for the faint of heart. I recommend it not only for its comprehensive review of L=λW but also (and mostly) for its exhaustive reference list. Work your way through all of the articles listed at the end of this paper, and you can truly call yourself an expert on Little's Law. If you read all of these, then you can pretty much ignore any other blog or LinkedIn post (or Wikipedia article, for that matter) that references Little's Law. Regardless of the effort that you put in, however, expertise in LL is not the end goal. No, the end goal is altogether different. Why You Really Should Care If you are studying Little's Law, it is probably because you care about process improvement. Chances are the area of process improvement that you care most about is predictability. Remember that being predictable is not completely about making forecasts. The bigger part of predictability is operating a system that behaves in a way that we expect it to. By designing and operating a system that follows the assumptions set forth by Little's Law, we will get just that: a process that behaves the way we expect it to. That means we will have controlled the things that we can control and that the interventions that we take to make things better will result in outcomes more closely aligned with our expectations. That is to say, if you know how Little's Law works, then you know how flow works. And if you know how flow works, then you know how value delivery works. I hope you have enjoyed this series and would welcome any comments or feedback you may have. Thanks for going on this learning journey with me! Explore all entries in this series When an Equation Isn't Equal A (Very) Brief History of Little's Law The Two Faces of Little's Law One Law. Two Equations It's Always the Assumptions The Most Important Metric of Little's Law Isn't In the Equation How NOT to use Little's Law Other Myths About Little's Law Little's Law - Why You Should Care (this article) About Daniel Vacanti, Guest Writer Daniel Vacanti is the author of the highly-praised books "When will it be done?" and "Actionable Agile Metrics for Predictability" and the original mind behind the ActionableAgile™️ Analytics Tool. Recently, he co-founded ProKanban.org, an inclusive community where everyone can learn about Professional Kanban, and he co-authored their Kanban Guide. When he is not playing tennis in the Florida sunshine or whisky tasting in Scotland, Daniel can be found speaking on the international conference circuit, teaching classes, and creating amazing content for people like us.

This is post 8 of 9 in our Little's Law series. In the previous blog post, we talked about the single biggest error people make when applying Little's Law. That's not to say there aren't others out there. Thankfully, Prateek Singh and I recorded an episode of our Drunk Agile podcast to go over some of these other myths in more detail. While a large portion of what we talk about below is a rehash of the forecasting debacle, we also get into lesser-known problems like: 1. Using LL to set WIP Limits 2. "Proving" LL using Cumulative Flow Diagrams 3. All items need to be the same size 4. Cycle Times must be normally distributed 5. FIFO queuing is required BTW, you will recall from a previous post where I quoted Little as saying, "...but it is quite surprising what we do not require. We have not mentioned how many servers there are, whether each server has its own queue or a single queue feeds all servers, what the service time distributions are, what the distribution of inter-arrival times is, or what is the order of service of items, etc." (1). If Little himself says that these are myths, who are we to disagree? So grab your favourite whisky and enjoy! References Little, J. D. C., S. C. Graves. 2008. Little's Law. D. Chhajed, T. J. Lowe, eds. Building Intuition: Insights from Basic Operations Management Models and Principles. Springer Science + Business Media LLC, New York. Drunk Agile YouTube channel https://www.youtube.com/@drunkagile4780 Explore all entries in this series When an Equation Isn't Equal A (Very) Brief History of Little's Law The Two Faces of Little's Law One Law. Two Equations It's Always the Assumptions The Most Important Metric of Little's Law Isn't In the Equation How NOT to use Little's Law Other Myths About Little's Law (this article) Little's Law - Why You Should Care About Daniel Vacanti, Guest Writer Daniel Vacanti is the author of the highly-praised books "When will it be done?" and "Actionable Agile Metrics for Predictability" and the original mind behind the ActionableAgile™️ Analytics Tool. Recently, he co-founded ProKanban.org, an inclusive community where everyone can learn about Professional Kanban, and he co-authored their Kanban Guide. When he is not playing tennis in the Florida sunshine or whisky tasting in Scotland, Daniel can be found speaking on the international conference circuit, teaching classes, and creating amazing content for people like us.

This is post 7 of 9 in our Little's Law series. You may or may not be surprised to hear me say that the Little's Law equation is indeed deterministic. But, as I have mentioned several times in the past, it is not deterministic in the way that you think it is. That is, the law is concerned with looking backward over a time period that has already been completed. It is not about looking forward; that is, is not meant to be used to make deterministic predictions. As Dr. Little himself says about the law, "This is not all bad. It just says that we are in the measurement business, not the forecasting business". (1) In other words, the fundamental way to NOT use Little's Law is to use it to make a forecast. Let me explain, as this is a sticking point for many people (again, most interwebs blog posts get this wrong). The "law" part of Little's Law specifies an exact (deterministic) relationship between average WIP, average Cycle Time, and average Throughput, and this "law" part only applies only when you are looking back over historical data. The law is not about—and was never designed for—making deterministic forecasts about the future. Little's Law wasn't designed for making deterministic forecasts about the future. For example, let's assume a team that historically has had an average WIP of 20 work items, an average Cycle Time of 5 days, and an average Throughput of 4 items per day. You cannot say that you are going to increase average WIP to 40, keep average Cycle Time constant at 5 days, and magically, Throughput will increase to 8 items per day—even if you add staff to keep the WIP to staff ratio the same in the two instances. You cannot assume that Little's Law will make that prediction. It will not. All Little's Law will say is that an increase in average WIP will result in a change to one or both of average Cycle Time and average Throughput. It will further say that those changes will manifest themselves in ways such that the relationship among all three metrics will still obey that law. But what it does not say is that you can deterministically predict what those changes will be. You have to wait until the end of the time interval you are interested in and look back to apply the law. The reason for the above is because--as we saw in the last post--it is impossible to know which of Little's assumptions (or how many times) you will violate in the future. As a point of fact, any violation of the assumptions will invalidate the law (regardless of whether you are looking backward or forward). But that restriction is not fatal. The proper application of Little's Law in our world is to understand the assumptions of the law and to develop process policies that match those assumptions. If the process we operate conforms—or mostly conforms—to all of the assumptions of the law, then we get to a world where we can start to trust the data that we are collecting from our system. It is at this point that our process is probabilistically predictable. Once there, we can start to use something like Monte Carlo simulation on our historical data to make forecasts, and, more importantly, we can have some confidence in the results we get by using that method. There are other, more fundamental reasons why you do not want to use Little's Law to make forecasts. For one thing, I have hopefully by now beaten home the point that Little's Law is a relationship of averages. I mention this again because even if you could use Little's Law as a forecasting tool (which you cannot), you would not want to, as you would be producing a forecast based on averages. Anytime you hear the word "average," you must immediately think "Flaw of Averages" (2). As a quick reminder, the Flaw of Averages (crudely) states that "plans based on average assumptions will fail on average." So, if you were to forecast using LL, then you would only be right an average amount of the time (in other words, you would most likely be wrong just as often as you were right--that's not very predictable from a forecasting perspective). Plans based on average assumptions will fail on average Having said all that, though, there is no reason why you cannot use the law for quick, back-of-the-envelope type estimations about the future. Of course, you can do that. I would not, however, make any commitments, WIP control decisions, staff hiring or firing decisions, or project cost calculations based on this type of calculation alone. I would further say that it is negligent for someone even to suggest doing so. But this simple computation might be useful as a quick gut check to decide if something like a project is worth any further exploration. While using Little's Law to forecast is a big faux pas, there are other myths that surround it, which we will cover very quickly in the next post in the series. References Little, J. D. C. *Little's Law As Viewed on Its 50th Anniversary* https://people.cs.umass.edu/~emery/classes/cmpsci691st/readings/OS/Littles-Law-50-Years-Later.pdf Savage, Sam L. *The Flaw of Averages*. John Wiley & Sons, Inc., 2009. Vacanti, Daniel S. *Actionable Agile Metrics for Predictability* ActionableAgile Press, 2014. Explore all entries in this series When an Equation Isn't Equal A (Very) Brief History of Little's Law The Two Faces of Little's Law One Law. Two Equations It's Always the Assumptions The Most Important Metric of Little's Law Isn't In the Equation How NOT to use Little's Law (this article) Other Myths About Little's Law Little's Law - Why You Should Care About Daniel Vacanti, Guest Writer Daniel Vacanti is the author of the highly-praised books "When will it be done?" and "Actionable Agile Metrics for Predictability" and the original mind behind the ActionableAgile™️ Analytics Tool. Recently, he co-founded ProKanban.org, an inclusive community where everyone can learn about Professional Kanban, and he co-authored their Kanban Guide. When he is not playing tennis in the Florida sunshine or whisky tasting in Scotland, Daniel can be found speaking on the international conference circuit, teaching classes, and creating amazing content for people like us.

This is post 6 of 9 in our Little's Law series. As we discussed in the previous post, a thorough understanding of what it means to violate each of the assumptions of Little's Law (LL) is key to the optimization of your delivery process. So let's take a minute to walk through each of those in a bit more detail. The first thing to observe about the assumptions is that #1 and #3 are logically equivalent. I'm not sure why Dr. Little calls these out separately because I've never seen a case where one is fulfilled but the other is not. Therefore, I think we can safely treat those two as the same. But more importantly, you'll notice what Little is not saying here with either #1 or #3. He is making no judgment about the actual amount of WIP that is required to be in the system. He says nothing of less WIP being better or more WIP being worse. In fact, Little couldn't care less. All he cares about is that WIP is stable over time. So while having arrivals match departures (and thus unchanging WIP over time) is important, that tells us *nothing* about whether we have too much WIP, too little WIP, or just the right amount of WIP. Assumptions #1 and #3, therefore, while important, can be ruled out as *the* most important. Assumption #2 is one that is frequently ignored. In your work, how often do you start something but never complete it? My guess is the number of times that has happened to you over the past few months is something greater than zero. Even so, while this assumption is again of crucial importance, it is usually the exception rather than the rule. Unless you find yourself in a context where you are always abandoning more work than you complete (in which case you have much bigger problems than LL), this assumption will also not be the dominant reason why you have a suboptimal workflow. This leaves us with assumption #4. Allowing items to age arbitrarily is the single greatest factor as to why you are not efficient, effective, or predictable at delivering customer value. Stated a different way, if you plan to adopt the use of flow metrics, the single most important aspect that you should be paying attention to is not letting work items age unnecessarily! More than limiting WIP, more than visualizing work, more than finding bottlenecks (which is not necessarily a flow thing anyway), the only question to ask of your flow system is, "Are you letting items age needlessly?" Get aging right and most of the rest of predictability takes care of itself. As this is a blog series about Little's Law, getting into the specifics of how to manage item aging is a bit beyond our remit, but thankfully Julia Wester has done an excellent job of giving us an intro to how you might use ActionableAgile Analytics for this goal. To me, one of the strangest results in all of flow theory is that the most important metric to measure is not really stated in any equation (much less Little's Law). While I always had an intuition that aging was important, I never really understood its relevance. It wasn't until I went back and read the original proofs and subsequent articles by Little and others that I grasped its significance. You'll note that other than the Kanban Guide, all other flow-based frameworks do not even mention work item aging at all. Kinda makes you wonder, doesn't it? Having now explored the real reasons to understand Little's Law (e.g., pay attention to aging and understand all the assumptions), let's now turn our attention to some ways in which Little's Law should NOT be used. Explore all entries in this series When an Equation Isn't Equal A (Very) Brief History of Little's Law The Two Faces of Little's Law One Law. Two Equations It's Always the Assumptions The Most Important Metric of Little's Law Isn't In the Equation (this article) How NOT to use Little's Law Other Myths About Little's Law Little's Law - Why You Should Care About Daniel Vacanti, Guest Writer Daniel Vacanti is the author of the highly-praised books "When will it be done?" and "Actionable Agile Metrics for Predictability" and the original mind behind the ActionableAgile™️ Analytics Tool. Recently, he co-founded ProKanban.org, an inclusive community where everyone can learn about Professional Kanban, and he co-authored their Kanban Guide. When he is not playing tennis in the Florida sunshine or whisky tasting in Scotland, Daniel can be found speaking on the international conference circuit, teaching classes, and creating amazing content for people like us.