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.

Get In Touch First Name Last Name Email Phone Subject Message Submit Thanks for getting in touch! We will respond to your message as soon as possible.

Be predictable. Be confident. Be agile. Trusted globally by 1600+ companies Powerful solutions that take you from busy to effective ActionableAgile ™️ Analytics Agile Flow Metrics for Jira, Azure DevOps, or standalone SaaS Measure and improve Flow. Be Predictable. Answer "When will it be done?" Learn More Portfolio Forecaster Continuous Forecasting for Jira Forecast Jira epics and versions with confidence using probabilities. Learn More Klar for Jira Cloud Configure & answer refinement questions for your work. Know just enough to start! Learn More Inspekt for Jira Cloud Analyze raw workflow data for cumulative time in status and how items move in the workflow. Learn More Products Julie Starling - Agile Delivery CoP Manager Financial Services Organization with over 1400 employees By regularly forecasting with ActionableAgile, we could clearly show when circumstances impacted our delivery timescales; previously, these would have been recognized as affecting our delivery. Monte Carlo simulation's what-if scenario planning function has enabled us to discuss what is happening and if trends are changing with stakeholders and teams. This allowed us to take meaningful action at the soonest possible opportunity and put the decisions with the right people. Recent Blog Posts José Coignard Jan 22 11 min Arrêtez par Toutatis avec vos "story points! This article is a guest contribution from José Coignard, ActionableAgile customer, Professional Kanban Trainer, and Agile Coach in... 128 1 like. Post not marked as liked 1 Victor Agbebo Jan 9 2 min 55 Degrees at Øredev Developer Conference, 2023 At the heart of Malmö, Sweden, where innovation meets inspiration, 55 Degrees once again took center stage at the Øredev Developer... 46 Post not marked as liked Julia Wester Dec 14, 2023 4 min 55 Degrees is now SOC 2 Compliant 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... 99 Post not marked as liked Read more > A culture based on security and privacy An important part of living up to our values is our commitment to data privacy and security throughout all aspects of our organization. We don't take a single step without ensuring we've taken all reasonable steps to protect your data and privacy. Protect customer and personal data at all times Comply with applicable privacy regulations Avoid processing or storing unneeded data Compliance Certifications and Standards ISO 27001 GDPR Atlassian Security Programs Interact with us at an upcoming event Atlassian Team '24 Tue, Apr 30 The Venetian Convention and Expo Center Apr 30, 2024, 7:00 AM PDT – May 02, 2024, 4:00 AM PDT The Venetian Convention and Expo Center, 201 Sands Ave, Las Vegas, NV 89169, USA Apr 30, 2024, 7:00 AM PDT – May 02, 2024, 4:00 AM PDT The Venetian Convention and Expo Center, 201 Sands Ave, Las Vegas, NV 89169, USA We’re sponsoring Atlassian Team'24 in Las Vegas from April 30 - May 2, 2024, and we’d love to meet with you there! +2 more RSVP More events >

Optimize Customer Value with a Proven Partner in Your Corner As the premier provider of Agile apps, 55 Degrees believes partnership extends beyond mere transactions. It's about forging meaningful connections and enabling our partners in any way possible. Become a Partner Already a Partner? Our Partner Types Atlassian Solution Partners Agile Trainers & Coaches License Resellers Strategic Partners Discover our partnership opportunities Dedicated Partner Manager Free Internal Licenses Financial Incentives Product Training & Educational Resources Sales & Product Enablement Optional Co-Marketing Opportunities Frequently Asked Questions How do I get product support? Reach out to our support team via our support portal at https://support.55degrees.se or via email at support@55degrees.se (which will create a ticket in our support portal). Our support portal is also where you can find our product documentation and much other helpful content! Where can I find your customer agreements for your products? You can always find the link in the footer of any page on our website. Our customer agreement for cloud products is located at https://www.55degrees.se/agreement-cloud-products and the customer agreement for on-premise products is located at https://www.55degrees.se/agreement-onprem-products . Do you have any security compliance certifications like SOC 2 or ISO 27001? Yes! We are ISO 27001 certified and are SOC 2 Type 2 compliant. You can download these items and see other key documents and technical measures via our 3rd-party trust center at https://trust.55degrees.se. You can also visit https://55degrees.se/trust to get a holistic idea of how we approach security at 55 Degrees! Is my data secure? We process your work data in real-time when you tell the app to load data. We do not export any of your work data from where it lives. When we do store data, we store configurations only, and we keep those secure. Please see our DPA (Cloud or OnPrem) and our privacy policy for more details. What is the licensing model? Do we pay per user? If you are purchasing our Jira app via the Atlassian Marketplace, their rules apply. That means that all users in your instance must be licensed. There's no need to worry, however, because you’re not charged the standard per-user price that you see in our other versions. In fact, you can often license all of your Jira users for less cost than a smaller number of users in our other versions. If you purchase a subscription to our SaaS or Azure apps, you will pay per user via a monthly or yearly subscription. You can have multiple users on a subscription. Please see our pricing page for more details. Product Support Reach out to our support team via our support portal at https://support.55degrees.se or via email at support@55degrees.se (which will create a ticket in our support portal). Our support portal is also where you can find our product documentation and much other helpful content! Join the Community You can join the 55 Degrees community at https://community.55degrees.se. Our community is run on the Mighty Networks platform and subject to both their privacy policy and ours. In this community you can get announcements from us, chat with others customers using our products, and even take online courses (both free and premium)! We can't wait to see you there! Security & Compliance We have information about our company's security efforts on our website at https://55degrees.se/trust. Check out our guiding principles, frameworks we're compliant with, security partners, as well as key documents like subprocessor lists. Want to download certificates, audit reports, or see more about our technical operational measures (TOMs)? Please visit our 3rd party trust center hosted by Vanta, at https://trust.55degrees.se. If you would like access to the more sensitive documents marked with a lock icon, you can request access and go through our NDA process, after which the materials will be available for download. If you have other questions about our security or compliance measures, please contact us via our support portal at https://support.55degrees.se. Customer Agreements You can always find the link in the footer of any page on our website. Our customer agreement for cloud products is located at https://www.55degrees.se/agreement-cloud-products and the customer agreement for on-premise products is located at https://www.55degrees.se/agreement-onprem-products . What is the procedure for initiating a trial of 55 Degrees apps and obtaining a partner license code? For a hands-on experience with our apps, submit a support ticket here, specifying which apps you're interested in trialing. We'll guide you through the process and provide you with the necessary license codes. What types of support and training programs are available to partners from 55 Degrees? At 55 Degrees, we offer a range of training and support options to empower our partners. Whether you need in-depth workshops, on-site training sessions, or just a basic introduction to our applications and how they address specific challenges, we have you covered. To arrange for a personalized training experience or for any support-related inquiries, please reach out to our partner manager at brodie@55degrees.se, or feel free to submit a support ticket through our helpdesk system. How can I access detailed information about the security and compliance features of your apps? You can learn about our robust security measures and compliance standards at our Trust Center (https://www.55degrees.se/trust). We provide comprehensive information outlining our security processes, emphasizing our commitment to being a leader in marketplace security. Partnering for Success Join our Partner Network. Together, we can achieve more. Become a Partner Already a Partner? Login to Partner Portal