Podcasts about story points

Are Story Points Helping Your Team?Story Points have been around for a couple decades now. There are countless articles and videos demonstrating their usage. Many organizations mandate their usage and teaching them are part of the standard approach for consulting organizations.For as long as I've known about Story Points (SP) and the associated velocity there continue to be far too many teams that have constant incomplete work Sprint after Sprint. Teams spend endless hours haggling over point estimation and still get it wrong so much of the time. There is elaborate theater in many teams at the end of the Sprint, renegotiating SP estimates for work that was harder than anticipated. Or splitting incomplete work and then attempting to determine where to place the Story Points.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Chris Sims: When Terminology Creates Misunderstandings, The "Ideal Days" Story Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this insightful episode, Chris Sims shares a valuable lesson from his early days implementing XP and Scrum. Chris's team had established an effective workflow using relative estimation with "ideal days" rather than story points, achieving good predictability and velocity measurements. However, things took an unexpected turn when a skeptical VP discovered their tracking spreadsheet and misinterpreted their metrics as showing only 2.5 days of work per week. Despite Chris's best efforts to explain the concept of "ideal days," the misunderstanding tarnished the team's reputation. Chris emphasizes the importance of socializing your working methods with stakeholders and communicating in ways meaningful to leadership. Working "under the radar" can backfire, so transparency about your processes is crucial for organizational alignment and trust. Self-reflection Question: How transparent are you about your team's estimation methods with stakeholders who might not be familiar with agile terminology? [Scrum Master Toolbox Podcast Recommends]

As product managers and agile practitioners, we often struggle to communicate our value to management in terms they understand.In this episode, you'll learn how to better translate business value to management, make a case for additional resources, and overcome resistance to change in your organization.Join Product Manager Brian Orlando and Enterprise Business Agility Coach Om Patel as we discuss:Translating agile metrics into business valueMaking a case for additional resources in SMBsOvercoming resistance to change in organizationsBalancing new features with technical debt reductionStrategies for demonstrating ROI of agile practices#ProductManagement #AgileLeadership #BusinessValue #OrganizationalChange #TechnicalDebt= = = = = = = = = = = =Watch it on YouTube= = = = = = = = = = = =Subscribe to our YouTube Channel:https://www.youtube.com/channel/UC8XUSoJPxGPI8EtuUAHOb6g?sub_confirmation=1Apple Podcasts:https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596Spotify:https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3= = = = = = = = = = = =Toronto Is My Beat (Music Sample)By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Converting Story Points to Money - Mike Cohn It's often worthless to tell a boss, client, or customer that a project will be done in, say, 142 story points.Even if stakeholders fully understand what a story point is, telling them how many points a project will take or cost isn't awfully helpful to them.These stakeholders are accustomed to hearing how much time and money a project will take. And it's important that teams and their leaders communicate with stakeholders in the terms those stakeholders prefer.Fortunately, it is quite straightforward to convert an estimate of points into money. Here's how. From Points to DollarsTo start, gather data on how much the team has been paid over a period of time. Ideally this should be at least a few months, but you could start with as little as one sprint.Next, divide total team compensation by the number of story points delivered by the team in that period. This gives you a cost per point.For example, suppose a team has been paid $100,000 over some period. During the same period, the team delivered 100 story points. Dividing $100,000 by 100 gives a cost per point of $1,000.This can then be multiplied by the total expected size of the project to give an estimate of the total financial cost. Getting Fancy (If You Want)You can get fancy with this calculation, if you'd like. Instead of using compensation as I did in this example, you might want to use fully loaded labor cost. As its name implies, this includes compensation as well as other costs such as benefits, overhead, and payroll expenses (taxes, Social Security in the U.S., etc.).A company controller can easily (and usually immediately) provide this as a percentage. It will typically be in the range of 25–40% added to compensation.You can get fancy by trying to adjust for seasonality or team size changes. However, that's usually not worth the effort: it shouldn't significantly impact the cost per point.Keep it simple.Clearly communicating expected costs with your stakeholders will improve your relationship with them. Everyone appreciates being communicated with in terms they understand. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Урааа! День знаний отгремел — снова в школу! За новыми уроками, знаниями и.. оценками!

Story Points Are NOT Trash! Recently, I noticed another ‘Story Points are trash' article on LinkedIn. It was a popular post, with many people responding to AND agreeing with this statement. I disagree.

More often than not, team members estimate story points based on time—something we're advised to avoid. Jeff Wilson, iSPCT candidate with RTX explains why and shares a key tip to help teams correctly and realistically estimate their story points. Like what you hear? Connect with Jeff on LinkedIn. Explore SAFe courses here. Read the Framework article on Stories here.

Are User Stories & Story Points Required? No... - Mike Cohn I'm often asked if user stories are part of Scrum.No, they're not. You can have a phenomenally successful team and never work with user stories at all.At its core Scrum is a very small set of rules. The Scrum rules are defined in the Scrum Guide, and they're things like keeping sprints short, no longer than a month.Outside this core of rules are the generally accepted Scrum practices. These are good ideas every Scrum Master should be aware of, but that a team doesn't necessarily need to do. User stories fit here.A great Scrum Master should know what user stories are. They may think stories are awful and not recommend using them for a team, but they should at least know what they are.What about Story Points?Story points are another generally accepted Scrum practice that isn't officially part of Scrum.Story points are a useful way for team members to agree on an estimate. Points get around a common problem: A senior team member thinks something will take one day, a junior team member thinks two days, and they're both right depending on who does the task.I think story points are great because they help you avoid pointless debates, they save time, and they increase the chances that your estimates will be accurate. They are my recommended unit for estimating product backlog items.But not every team needs to estimate! And you certainly don't have to use story points if you do estimate–you can use person days or some other unit if you prefer.I do, however, think that you should give story points and user stories a try. For the majority of teams, they are both great practices that will help you succeed with agile, How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Velocity ist in der agilen Softwareentwicklung, vor allem in Scrum, weit verbreitete Metrik, die die Arbeitsmenge eines Teams in einem Sprint misst. Aber ihre Nutzung birgt auch bestimmte Grenzen, die Tim und Dominique in dieser Folge kritisch hinterfragen. Velocity, meist in Story Points gemessen, gibt an, wie viel ein Team in einem (durchschnittlich) Sprint leistet. Sie ist hilfreich für die Sprint-Planung und kann die Vorhersagbarkeit verbessern. Doch als reine Output-Metrik vernachlässigt sie wichtige Aspekte wie Outcome und die Qualität der Arbeit. Ein kritischer Punkt, den Tim und Dominique betonen, ist, dass Velocity eine relative Größe ist, die nur innerhalb eines Teams Bedeutung hat. Der Vergleich von Velocity zwischen verschiedenen Teams ist problematisch und kann vorsichtig gesagt mindestens zu Missverständnissen führen. In der Diskussion heben die beiden hervor, dass Teams Velocity als Werkzeug zur Reflexion nutzen sollten, nicht als starres Ziel. Es geht darum, den tatsächlichen Wert und die Qualität der Arbeit zu verbessern - nicht um die reine Liefergeschwindigkeit als Selbstzweck. Andere Metriken, die Kundenzufriedenheit und Outcome zu messen, erscheinen sogar wichtiger zu sein. Interessanter Weise wurde die Velocity früher in Scrum Trainings viel stärker betont, Zusammen mit dem allgemeinen Trend, mehr Wert auf Outcome bzw. Wirkung zu legen, statt eine reine Product Delivery zu fokussieren, wird auch in den Trainings immer seltener über Velocity gesprochen. Neben den Problemen und Fehlern im Umgang mit Velocity betrachten Dominique und Tim natürlich auch die Vorteile des Einsatzes dieser Metrik. Weiterhin geben sie Tipps zum richtigen Einsatz von Velocity. In dieser Folge wird auf diese Episoden im Gespräch verwiesen: - Wann ist das fertig? Keine Ahnung, wir sind ja agil! - Forecasting in der agilen Produktentwicklung - Evidence Based Management - eine empirische Suche nach Wert Nutzt ihr bei euch Velocity als Metrik? Wenn ja, wie gelingt es euch, dass diese Metrik auch positiv im Hinblick auf den Wert des entwickelten Produkts wirkt und nicht zu einem Team-Kontrollinstrument verkommt? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Josh Lambert: Introducing Estimation Consistency To An Agile Team With The Help Of Cycle Time Metrics Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Josh shares his experience initiating change within a high-performing team. Silent observations revealed inconsistent cycle times and unstable story points. Recognizing a lack of focus and attention during story sizing, he implemented an internal sprint review and emphasized the impact on the Product Owner's decisions. Collaborating with the PO, a shared message strengthened planning consistency. Eventually, the team achieved shorter cycle times, and addressed bottleneck issues.   [IMAGE HERE] As Scrum Master we work with change continuously! Do you have your own change framework that provides the guidance, and queues you need when working with change? The Lean Change Management framework is a fully defined, lean-startup inspired change framework that can be used as the backbone of any change process! You can buy Lean Change Management the book at Amazon. Also available in French, Spanish, German and Portuguese.   About Josh Lambert Josh is an Agile Coach at a financial institution. He has been through a few different Agile Transformations. And became a Scrum Master in one of the early transformations and loved the role where where he stayed for 6 years, after which he transitioned into an Agile Coach. You can link with Josh Lambert on LinkedIn.

3 Tips to Help You Understand Objective Story Points 1) NEVER associate points and time - Understand the container concept 2) Break things down so that each story is indeed consumable 3) Make certain you have the right people in the room when breaking down and refining stories How to connect with AgileDad: - [website] ⁠https://www.agiledad.com/⁠ - [instagram] ⁠https://www.instagram.com/agile_coach/⁠ - [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠ - [Linkedin] ⁠https://www.linkedin.com/in/leehenson/⁠

Story Points, die magische Kennzahl eines jeden agilen Projekts. Aber ist das überhaupt richtig? Was sind Story Points, wie und vor allem warum werden sie überhaupt genutzt? Diese Fragen beantwortet euch heute Christian Bosold aus der #agileleaderinitiative. Dir hat diese Folge gefallen? Dann liken, kommentieren, weitersagen! Nur so können viele andere Hörer auch von diesem kostenlosen Mehrwert profitieren. --- Du möchtest mit uns sprechen oder in Kontakt treten? Kein Problem! Website: www.agileleaderinitiative.com.com E-Mail: office@agileleaderinitiative.com Linkedin: https://www.linkedin.com/company/sascha-oehlbrecht-gmbh/?viewAsMember=true Instagram: https://www.instagram.com/saschaoehlbrecht/- Direkt einen kostenlosen Strategie-Call buchen: https://agileleaderinitiative.com/kontakt --- Wer sind wir? Die Agile Leader Initiative ist ein Unternehmen im wunderschönen Südniedersachsen bei Göttingen. Wir sind ein Team von Experten für Agilität in Zusammenarbeit, Führung und Projektmanagement. Gemeinsam mit unseren Kunden lüften wir dadurch die Geheimnisse für wahre Umsetzungsstärke und ermöglichen erfolgreiche Teams. Dies tun wir mit unseren einzigartigen Trainings-, Coachings- und Projektbgeleitungsangeboten sowie Vorträgen. Die (Arbeits-)Welt ist unsicherer, sprunghafter und komplexer denn je, mit unseren Ansätzen führen wir unsere Kunden zum Erfolg. --- Bis bald und alles Gute das Team der Agile Leader Initiative

How Do You Teach others About Story Points? It's nearly back-to-school time where I live. I can almost smell the new spiral notebooks and freshly sharpened pencils!What are your back-to-school plans? Do any of them involve building your agile skills? I want to help. For the next six weeks, I'll send a tip per week on common Scrum and agile topics, with three practical pointers for each. Every pointer includes a link to a blog or video for a more in-depth explanation.Our first back-to-school topic is how to introduce story points to your team.Tip # 1: Start with What Story Points AreStory points abstract units of measure for expressing an estimate of the overall effort required to implement a product backlog item or any other piece of work. With story points, the raw values are meaningless. What matters is the ratio between the numbers.Tip #2: Tell the Team the Main Benefit of Story PointsThe main reason to use story points is that they allow team members with different skill levels to communicate about and agree on an estimate, because with story points it's all relative.Suppose you are a classically trained French chef. I, on the other hand, struggle to boil water. We are not going to chop an onion in the same amount of time. You'll always go faster. So if we had to tell someone precisely how long it takes to chop an onion, we'd never agree on a number.But we're using story points. And because we are, we don't have to agree on precise times, we just have to decide on the relative effort it will take to chop an onion.So let's imagine that we decide that chopping an onion is a 2–it's not the easiest thing we could chop, but it's not too difficult.From there, we ask ourselves: how does chopping a pineapple compare to chopping an onion? We decide it's about 2 times more effort to get a pineapple peeled, cored, and diced. So we agree to call it a 4.We could have called the onion a 5. If we did, the pineapple would be a 10. The numbers don't matter. The relationship between the numbers is all we care about.Tip #3: Explain that Effort Considers Multiple FactorsStory points describe how long something will take in terms of relative effort. But effort takes several factors into account.Suppose we both agree that running from point A to point B is low effort (short, flat, no obstacles), so we call it a 1.From there, we can assess how much longer it will take to run from point A to point N. To come up with the new estimate, we consider multiple factors that go into determining effort:  Is it the same distance from A to N as from A to B? (volume) Is the terrain flat and even? Or rocky? Or uphill? (complexity) Does the path run along a sheer cliff or across a lava pit? Does it look unlike any other path we've encountered before? (risky/uncertain) Using this information, we arrive at an estimate of relative effort.How to connect with AgileDad: - [website] ⁠https://www.agiledad.com/⁠ - [instagram] ⁠https://www.instagram.com/agile_coach/⁠ - [facebook] ⁠https://www.facebook.com/RealAgileDad/⁠ - [Linkedin] ⁠https://www.linkedin.com/in/leehenson/⁠

Andrew Mitchell: Lessons in Change Management from Story Points to Flow Metrics in a Scrum Team Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Andrew discusses his change process of transitioning from traditional story point refinement to flow-based metrics and #NoEstimates. He faced resistance at the team and organizational levels. Andrew conducted an experiment using two years' worth of data, showing that story points were not superior to throughput. He presented the results to leadership and the teams, emphasizing the importance of holistic metrics and their impact on predictability and team dynamics. Andrew introduced t-shirt sizing for simpler estimation conversations and highlighted that counting stories was more predictive than relying solely on story points. The episode emphasizes lessons in change management, including metric selection and fostering collaboration and predictability. [IMAGE HERE] As Scrum Master we work with change continuously! Do you have your own change framework that provides the guidance, and queues you need when working with change? The Lean Change Management framework is a fully defined, lean-startup inspired change framework that can be used as the backbone of any change process! You can buy Lean Change Management the book at Amazon. Also available in French, Spanish, German and Portuguese.   About Andrew Mitchell Andrew prioritizes people when building products, aiming for happy and engaged employees who create great products and serve customers well. He emphasizes trust, psychological safety, servant leadership, and believes Scrum is the best framework to achieve these goals. He was also a host of the Product Owner Summit 2023, where we collaborated. You can link with Andrew Mitchell on LinkedIn.

I've done several podcast interviews over the past few months about Flow Metrics. These podcasts are all pretty much aligned around the fact that if you want metrics you can rely on to predict what to expect from your teams in the future, nothing is perfect, but flow metrics are better than velocity. Since most of the people I meet while I am coaching, or teaching use Jira, I reached out to a friend at Atlassian to learn more about how to get this data. Here's the best part… if you are using Jira, the system is probably already capturing the data for you, you just need an easy way to get at it… and this podcast Derek Huether and Sam Tsubota will show you just how easy it is to get at the information you need to understand more about you team's flow. (This podcast was originally recorded in video. If you'd like to watch that version you can find it here: https://youtu.be/q86HXsvvv04 ) If you'd like to check out the other podcasts I've done recently on flow metrics: Story Points are Good AND Evil with Ryan Ripley https://bit.ly/3vZvDzk Enabling Change with Data Modeling and Forecasting (with Troy Magennis) https://bit.ly/3JypeSF For more on Atlassian Analytics: https://bit.ly/3oZiaYt If you'd like to contact Derek or Sam Derek Huether LinkedIn: https://bit.ly/3poYSvF Web: derekhuether.com Twitter: https://twitter.com/derekhuether Amazon: https://bit.ly/3GPEQQQ Sam Tsubota LinkedIn: https://bit.ly/STsubota

Rayyan Karim: Measuring Success in Agile, Why Story Points Don't Always Tell the Full Agile Story Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Rayyan discusses two main categories for measuring performance in organizations: hard and fast business results and effectiveness. The first indicator for effectiveness is happy people who can be themselves, which Rayyan refers to as "Shiny Happy People." Rayyan suggests that instead of focusing on story points, teams should focus on cycle and lead time and examine the variation in the system to determine how to remove it. He recommends conducting team surveys or squad health checks over time and paying attention to how people talk at retrospectives. Additionally, Rayyan suggests setting up one-on-one meetings with team members to get a better understanding of how they are showing up for retrospectives. Featured Retrospective Format for the Week: The Squad Health Check retro benefits In this episode, Rayyan discusses his favorite agile retrospective format, which is the Squad Health Check. He mentions that while the Sailboat retro is the most commonly used, he prefers the Squad Health Check as it quickly gets everyone on the same page and can be used in larger teams and teams of teams. Rayyan notes that the Health Check is short, focused, and highly adaptable, and it gives a good understanding of where the teams are. He also gives tips to adapt it to the program or team you are working with and to remove the "neutral" option.   Retrospectives, planning sessions, vision workshops, we are continuously helping teams learn about how to collaborate in practice! In this Actionable Agile Tools book, Jeff Campbell shares some of the tools he's learned over a decade of coaching Agile Teams. The pragmatic coaching book you need, right now! Buy Actionable Agile Tools on Amazon, or directly from the author, and supercharge your facilitation toolbox!    About Rayyan Karim Rayyan is and Agile Coach & Trainer and the founder of Design Your Future with presence in the UK and the UAE. Rayyan is known for supporting leading executives of FTSE100 and NASDAQ corporations to create transformational results quickly. You can link with Rayyan Karim on LinkedIn and connect with Rayyan Karim on Twitter.

Todd and Ryan think that tracking individual story points in Dev supervision is a major problem and a red flag. They believe it is a reckless metric that can impact people's behavior and pit teammates against each other. Ryan cites a book, "Escape Velocity" by Doc Norton, which argues that measuring individual velocity fails to give a complete picture and likely gives the wrong impression. It also hides things and can provoke behaviors that are against teamwork. Todd thinks tracking individual story points could lead to fights and is a massive issue that should be avoided.  ⏩ Join Ryan and Todd for a Scrum.org's course: https://buytickets.at/agileforhumansllc

Stop using hour-based estimation for your work. There's a better way! Whether it's a project as a whole or just a Sprint, Story Points and Velocity are key tools in trying to predict the future and make the most of your team's time and effort. In this episode, Dan & George talk about how Story Points offer a means of estimation that is relative to a particular frame of reference, enabling you to get a more accurate understanding of your true Velocity. 

Join Lance Dacy and Brian Milner as they discuss the use of metrics in an Agile environment to ensure optimal performance without taking things in the wrong direction. Overview In this episode of the Agile Mentors podcast, Lance Dacy joins Brian to delve into the intricacies of utilizing metrics in software development to ensure optimal performance while avoiding incentivizing adverse behaviors. Listen in as he walks us through the three tiers of metrics that are crucial for Agile teams to consider in order to stay on course. He’ll share the tools required to gain a holistic understanding of an individual's performance and how leadership styles and stakeholders influence team-level metrics. Plus, a look at the common challenges that teams may encounter during their Agile adoption journey and how to overcome them. Listen now to discover: [01:18] - Lance Dacy is on the show to discuss metrics. [02:09] - Brian asks, are there ‘good’ ways to track performance? [02:32] - Lance shares why Agile doesn’t really lend itself to tracking performance. [03:57] - How to handle performance reviews. [04:32] - Lance shares the best way to measure individual performance. [06:40] - Measuring team contribution vs. standalone rockstar. [07:48] - What Ken Schwaber and Jeff Sutherland say about the completeness of the Scrum Framework and why having a superhero on your team is bad. [09:45] - Lance shares the 3 tiers of metrics to measure when working as an Agile team to be sure their team is going in the right direction. [11:09] - Using tangible business-level metrics such as time to market for products, NPS, and support call volume to evaluate performance. [12:20] - How metrics, such as the number of work items completed per month, and cycle time, can be used to evaluate performance at a product level in an Agile environment. [14:10] - Lance shares standard metrics such as velocity, backlog churn, and work-in-process that can be used to evaluate things at the team level. [14:45] - Brian shares the importance of having a broader perspective to avoid having a distorted view of performance. [16:53] - How using tools such as Ishikawa (fishbone) diagrams can help you identify the root cause of the problem instead of the apparent cause. [17:22] - Individual velocity and other big metrics to avoid. [19:02] - How the balanced scorecard can help managers use ALL the information available to develop a comprehensive understanding of an individual's performance. [19:25] - The detrimental effects of using the wrong metrics to evaluate an individual's contribution. [21:29] - Brian shares the story of how a manager's bug squashing endeavor led to incentivizing the wrong behavior [22:31] - Lance references Stephen Denning's statement and reminds us that assumption testing is what developers do every day. [24:00] - Referencing the State of Agile Report statistics on what's stalling your transformation to Agile. [25:15] - Lance shares a behind-the-scenes look at how team-level metrics are affected by leadership styles and stakeholders. [27:05] - Lance shares the spreadsheet he's been using to track data for a Scrum team for over 5 years to understand why the team is not predictable and what they can do to improve. [31:38] - Got metrics management questions? Reach out to Lance. [31:46] - Why it’s imperative that you think of software development as R&D rather than manufacturing to arrive at the right metrics measurements. [33:26] Continue the conversation in The Agile Mentors Community. References and resources mentioned in the show: Join the More than 24k People Who've Trained to Succeed With Mountain Goat Software Mountain Goat Software Certified Scrum and Agile Training Schedule #30: How to Get the Best Out of the New Year with Lance Dacy #31: Starting Strong: Tips for Successfully Starting with a New Organization with Julie Chickering State of Agile Report HBR's Embrace Of Agile The Agile Mentors Community Additional metrics resources mentioned by Lance Agile Metrics Business outcomes, product group metrics, unit metrics) KPI/OKR (Business Outcomes) Time to market, NPS, Support Call Volume, Revenue, Active Account, New Customer Onboarding Time, Regulatory Violations) Product Group Metrics Work items completed per unit of time (quarterly) % of work in active state vs. wait state Cycle time of work times (idea to done) Predictability (% of work items that reach ready when planned) Unit metrics Velocity, backlog churn, work in process, team stability Metrics Spreadsheet Team Size Tracking the size of our cross-functional team (typically Dev and QA), allows us to pair that number with velocity to play “what-if” scenarios in the future. Whether you count half of a person if shared, or whole, keeping it consistent throughout your tracking is what is important. Most teams simply count the number of developers and testers. Team Days Tracking the iteration length is also helpful in understanding a team’s performance. If the team has a 2 week sprint, then usually that is 9 development days of actual work. The 10th day is set aside for sprint review, retrospective, and planning. Committed Tracking what the team committed to completing within a sprint is crucial to understanding their predictability. The are the most uneducated at the beginning of the sprint and tracking what they think they can complete helps us in long term planning. Completed Tracking what the team completed is actually just tracking velocity above, but comparing it what they committed helps us understand their predictability index. Predictability Index (Pi) Software development is complex, risky, and uncertain. A skill that is sought after in this type of environment is predictability. The better we are at understanding what we can accomplish, then finishing what we said we would accomplish builds trust with our management team and customers. If we aren’t very good, tracking this metric often helps us get back to good by committing to less or more depending on our index. Example: Completed Items / Committed Items = Predictability Index (Pi) 25 Story Points / 20 Story Points = 125% 20 Story Points / 25 Story Points = 80% Just because a team has a high Pi, does not mean they are good at predictability. Don’t let high and low numbers fool you, focus on the variance from 100% instead of the actual number. An arbitrary number to shoot for is +/- 15% Pi (85% or 115%). Story Points / Per Day (SPD) Story points per day is just that, tracking how many story points per day of the sprint did we complete (Completed / Team Days). Story Points / Per Day / Per Person (SP/PD/PP) This perhaps is the most useful metric to capture throughout the process. Most of our teams do not have the luxury of maintaining a consistent size or make-up. Inevitably over the course of a few months, the team make-up will change. Once the teams change, velocity has to be reset. In addition, we may actually change our sprint duration over a long period of time (don’t change it each sprint). Once we change sprint lengths, it can jeopardize our pure metrics, velocity has to be reset. However, over all of our teams in a product, if we can capture the SP/PD/PP that our teams complete on average, we can begin to play “what-if” scenarios in long- term planning. Example: Completed / (Team Size * Sprint Days) 24 / (4 * 9) = 0.67 You can then average that number over 4-6 sprints or even the year. Defects While we understand that we won’t ever likely have a zero defect product, it is useful to track how many defects our teams are creating over time. There are usually 2 types of defects, internal and external. Internal Our definition of done should at minimum include that testing is taking place during the sprint with the idea that we would not allow a story to be called DONE if it had remaining defects. As such, an internal defect are the ones that were created while working on a backlog item in the sprint, that we have fixed before calling the item DONE. External External defects are those that have “escaped” our development process and were not discovered during our testing. In a sense, our customer discovered the defect and the work item will become a new backlog item for a sprint. Warranty We should strive to have the warranty concept built into our process. If you bought a car yesterday and the radio fell out, you could take it back and they would fix it fairly quickly. Our customers deserve the same service. Don’t manage a defect backlog, get used to fixing escaped defects immediately, while they are fresh on your mind (right after a sprint). It doesn’t take a long time to fix defects, it takes a long time to find them once identified by a customer. Defects per Story Point Tracking defects per story point help to understand velocity a little better. If you have a team that has drastically increased its velocity, have the defects have increased along with it? Defects per story point help us understand the relationship between a velocity and defects created. Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? It would be great if you left a rating and a review. It really helps, and we read every single one. Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He’s passionate about making a difference in people’s day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Lance Dacy, known as Big Agile, is a dynamic, experienced management and technical professional with the proven ability to energize teams, plan with vision, and establish results in a fast-paced, customer-focused environment. He is a Certified Scrum Trainer® with the Scrum Alliance and has trained and coached many successful Scrum implementations from Fortune 20 companies to small start-ups since 2011. You can find out how to attend one of Lance’s classes with Mountain Goat Software here.

Join Lance Dacy and Brian Milner as they discuss the use of metrics in an Agile environment to ensure optimal performance without taking things in the wrong direction. Overview In this episode of the Agile Mentors podcast, Lance Dacy joins Brian to delve into the intricacies of utilizing metrics in software development to ensure optimal performance while avoiding incentivizing adverse behaviors. Listen in as he walks us through the three tiers of metrics that are crucial for Agile teams to consider in order to stay on course. He’ll share the tools required to gain a holistic understanding of an individual's performance and how leadership styles and stakeholders influence team-level metrics. Plus, a look at the common challenges that teams may encounter during their Agile adoption journey and how to overcome them. Listen now to discover: [01:18] - Lance Dacy is on the show to discuss metrics. [02:09] - Brian asks, are there ‘good’ ways to track performance? [02:32] - Lance shares why Agile doesn’t really lend itself to tracking performance. [03:57] - How to handle performance reviews. [04:32] - Lance shares the best way to measure individual performance. [06:40] - Measuring team contribution vs. standalone rockstar. [07:48] - What Ken Schwaber and Jeff Sutherland say about the completeness of the Scrum Framework and why having a superhero on your team is bad. [09:45] - Lance shares the 3 tiers of metrics to measure when working as an Agile team to be sure their team is going in the right direction. [11:09] - Using tangible business-level metrics such as time to market for products, NPS, and support call volume to evaluate performance. [12:20] - How metrics, such as the number of work items completed per month, and cycle time, can be used to evaluate performance at a product level in an Agile environment. [14:10] - Lance shares standard metrics such as velocity, backlog churn, and work-in-process that can be used to evaluate things at the team level. [14:45] - Brian shares the importance of having a broader perspective to avoid having a distorted view of performance. [16:53] - How using tools such as Ishikawa (fishbone) diagrams can help you identify the root cause of the problem instead of the apparent cause. [17:22] - Individual velocity and other big metrics to avoid. [19:02] - How the balanced scorecard can help managers use ALL the information available to develop a comprehensive understanding of an individual's performance. [19:25] - The detrimental effects of using the wrong metrics to evaluate an individual's contribution. [21:29] - Brian shares the story of how a manager's bug squashing endeavor led to incentivizing the wrong behavior [22:31] - Lance references Stephen Denning's statement and reminds us that assumption testing is what developers do every day. [24:00] - Referencing the State of Agile Report statistics on what's stalling your transformation to Agile. [25:15] - Lance shares a behind-the-scenes look at how team-level metrics are affected by leadership styles and stakeholders. [27:05] - Lance shares the spreadsheet he's been using to track data for a Scrum team for over 5 years to understand why the team is not predictable and what they can do to improve. [31:38] - Got metrics management questions? Reach out to Lance. [31:46] - Why it’s imperative that you think of software development as R&D rather than manufacturing to arrive at the right metrics measurements. [33:26] Continue the conversation in The Agile Mentors Community. References and resources mentioned in the show: Join the More than 24k People Who've Trained to Succeed With Mountain Goat Software Mountain Goat Software Certified Scrum and Agile Training Schedule #30: How to Get the Best Out of the New Year with Lance Dacy #31: Starting Strong: Tips for Successfully Starting with a New Organization with Julie Chickering State of Agile Report HBR's Embrace Of Agile The Agile Mentors Community Additional metrics resources mentioned by Lance Agile Metrics Business outcomes, product group metrics, unit metrics) KPI/OKR (Business Outcomes) Time to market, NPS, Support Call Volume, Revenue, Active Account, New Customer Onboarding Time, Regulatory Violations) Product Group Metrics Work items completed per unit of time (quarterly) % of work in active state vs. wait state Cycle time of work times (idea to done) Predictability (% of work items that reach ready when planned) Unit metrics Velocity, backlog churn, work in process, team stability Metrics Spreadsheet Team Size Tracking the size of our cross-functional team (typically Dev and QA), allows us to pair that number with velocity to play “what-if” scenarios in the future. Whether you count half of a person if shared, or whole, keeping it consistent throughout your tracking is what is important. Most teams simply count the number of developers and testers. Team Days Tracking the iteration length is also helpful in understanding a team’s performance. If the team has a 2 week sprint, then usually that is 9 development days of actual work. The 10th day is set aside for sprint review, retrospective, and planning. Committed Tracking what the team committed to completing within a sprint is crucial to understanding their predictability. The are the most uneducated at the beginning of the sprint and tracking what they think they can complete helps us in long term planning. Completed Tracking what the team completed is actually just tracking velocity above, but comparing it what they committed helps us understand their predictability index. Predictability Index (Pi) Software development is complex, risky, and uncertain. A skill that is sought after in this type of environment is predictability. The better we are at understanding what we can accomplish, then finishing what we said we would accomplish builds trust with our management team and customers. If we aren’t very good, tracking this metric often helps us get back to good by committing to less or more depending on our index. Example: Completed Items / Committed Items = Predictability Index (Pi) 25 Story Points / 20 Story Points = 125% 20 Story Points / 25 Story Points = 80% Just because a team has a high Pi, does not mean they are good at predictability. Don’t let high and low numbers fool you, focus on the variance from 100% instead of the actual number. An arbitrary number to shoot for is +/- 15% Pi (85% or 115%). Story Points / Per Day (SPD) Story points per day is just that, tracking how many story points per day of the sprint did we complete (Completed / Team Days). Story Points / Per Day / Per Person (SP/PD/PP) This perhaps is the most useful metric to capture throughout the process. Most of our teams do not have the luxury of maintaining a consistent size or make-up. Inevitably over the course of a few months, the team make-up will change. Once the teams change, velocity has to be reset. In addition, we may actually change our sprint duration over a long period of time (don’t change it each sprint). Once we change sprint lengths, it can jeopardize our pure metrics, velocity has to be reset. However, over all of our teams in a product, if we can capture the SP/PD/PP that our teams complete on average, we can begin to play “what-if” scenarios in long- term planning. Example: Completed / (Team Size * Sprint Days) 24 / (4 * 9) = 0.67 You can then average that number over 4-6 sprints or even the year. Defects While we understand that we won’t ever likely have a zero defect product, it is useful to track how many defects our teams are creating over time. There are usually 2 types of defects, internal and external. Internal Our definition of done should at minimum include that testing is taking place during the sprint with the idea that we would not allow a story to be called DONE if it had remaining defects. As such, an internal defect are the ones that were created while working on a backlog item in the sprint, that we have fixed before calling the item DONE. External External defects are those that have “escaped” our development process and were not discovered during our testing. In a sense, our customer discovered the defect and the work item will become a new backlog item for a sprint. Warranty We should strive to have the warranty concept built into our process. If you bought a car yesterday and the radio fell out, you could take it back and they would fix it fairly quickly. Our customers deserve the same service. Don’t manage a defect backlog, get used to fixing escaped defects immediately, while they are fresh on your mind (right after a sprint). It doesn’t take a long time to fix defects, it takes a long time to find them once identified by a customer. Defects per Story Point Tracking defects per story point help to understand velocity a little better. If you have a team that has drastically increased its velocity, have the defects have increased along with it? Defects per story point help us understand the relationship between a velocity and defects created. Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? It would be great if you left a rating and a review. It really helps, and we read every single one. Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He’s passionate about making a difference in people’s day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Lance Dacy, known as Big Agile, is a dynamic, experienced management and technical professional with the proven ability to energize teams, plan with vision, and establish results in a fast-paced, customer-focused environment. He is a Certified Scrum Trainer® with the Scrum Alliance and has trained and coached many successful Scrum implementations from Fortune 20 companies to small start-ups since 2011. You can find out how to attend one of Lance’s classes with Mountain Goat Software here.

In this episode, host Troy Lightfoot chats with Ryan Ripley about his latest controversial social media posts about story points and his new mantra, "Story points are trash" We discuss why he feels that way, what are the alternatives, and how some of our "common" practices might be better left in the past if we want to progress. Links https://www.agileforumans.com https://www.linkedin.com/in/ryanripley https://ryanripley.com https://prokanban.org YadaYada  If you enjoyed this episode, please give us a review, a rating, or leave comments on iTunes, Stitcher or your podcasting platform of choice. It really helps others find us.  Much thanks to the artist Krebs from Machine Man Records who provided us our outro music free-of-charge!  If you like what you heard, check out these links to find more music you might enjoy! If you'd like to join the discussion and share your stories,  please jump into the fray at our Discord Server! We at the Agile Uprising are committed to being totally free.  However, if you'd like to contribute and help us defray hosting and production costs we do have a Patreon.  Who knows, you might even get some surprises in the mail!

A few weeks ago while I was teaching a CSM class, I got a Slack message from Ron Quartel pointing me to a tweet by Ryan Ripley. The tweet said “If you are sitting in a Scrum Training class and the trainer starts teaching Story Points, you should 1. Get up. 2. Demand Your Money Back, and 3. Walk out. You're wasting your time. Here is a link to the tweet: https://bit.ly/3XsfPAP I should mention I was just about to cover Story Points and I used Ryan's tweet in class as part of our conversation. As soon as I saw Ryan's tweet, I DM'd him asking if we could do a podcast about it. I did this because A) I have a lot of respect for Ryan and value his opinion, B) earlier in my career I spent about 4 years fighting against Story Points, C) I do teach them in class because I believe that (used properly) they can be incredibly valuable to a Scrum Team, and D) I love getting into debates on topics I feel strongly about with really smart people who might be able to change my mind So this podcast is Ryan and I talking through his reason for throwing shade on Story Points, my reasons for standing up for them, and the reasons I feel comfortable saying that we are aligned about why Story Points are good AND evil. This podcast was originally recorded in video. If you'd prefer that version you can find it here: https://youtu.be/-ja1oFv5Et0 Contacting Ryan: Web: https://AgileforHumans.com YouTube: https://www.youtube.com/@AgileforHumans Fixing Your Scrum by Ryan Ripley and Todd Miller: https://amzn.to/3Qyjs5S LinkedIn: https://www.linkedin.com/in/ryanripley/

Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant: Some teams use a modified fibonacci sequence (1, 2, 3, 5, 8, 13); others use a doubling sequence (1, 2, 4, 8, 16). What matters are the relative values. A user story that is assigned two story points should be twice as much effort as a one-point story. It should also be two-thirds the effort of a story that is estimated as three story points. Instead of assigning 1, 2 and 3, that team could instead have assigned 100, 200 and 300. Or 1 million, 2 million and 3 million. It is the ratios that matter, not the actual numbers. One of the main reasons story points are so valuable is that they allow team members with different skill levels to communicate about and agree on an estimate. Instead of arguing about how long it might take each team member personally to do something, teams instead can quickly say that this user story is about twice or three times as much effort as that user story. With story points, it's all relative.

Today, we speak again with Joe Ziadeh, the Chief Story Teller and Innovation Artist at Balanced Agility. He knows how estimation is done best by pinning it relative against the size of another thing and determining if it is bigger or smaller than that. Joe also talks about story points and how to relatively size them and use the Fibonacci sequence because it is simply what worked for many people a long time ago. Get to know Joe and what he's up to:About JoeAbout Balanced AgilityBalanced Agility WebsiteConnect with Vivek and find out more about what he's up to:About VivekAbout The Agile CoachAgile Coach WebsiteIf you enjoy The Agile Coach and are interested in learning more, you can check us out at the link below:LinkedIn: https://www.linkedin.com/company/the-agile-coach-llc

In this short segment, I share my perspective on what some enterprises get horribly wrong with story points in Agile estimation. Follow along on BarcVox.com, where you can also find related content. Transcript available for this segment: http://barcvox.com/2022/12/15/whats-the-story-with-story-points/ --- Send in a voice message: https://podcasters.spotify.com/pod/show/barcvox/message

Star Trek: First Contact: The Making of the Classic Film. Star Trek is one of the longest running franchises and yet the amount of reference books, art books and making-of books that come out is sorely lacking compared to something like Star Wars. In this episode of Literary Treks hosts Matthew Rushing and Casey Pettitt talk about Star Trek: First Contact: The Making of the Classic Film. We discuss the presentation, after Generations, story points, new Enterprise, new Borg, finding a director, or ratings and final thoughts. In the news section we talk about the end of the Stargazer comic mini series as well as the Ferengi one-shot. News Stargazer #3 (00:04:36) Star Trek: Ferengi (00:15:39) Feature: Star Trek: First Contact: The Making of the Classic Film Presentation (00:20:54) After Generations (00:25:56) Story Points (00:31:11) New Enterprise (00:37:12) New Borg (00:41:58) Finding a Director (00:45:46) Ratings (00:50:30) Final Thoughts (00:53:12) Hosts Matthew Rushing and Casey Pettitt Production Matthew Rushing (Editor and Producer) C Bryan Jones (Executive Producer) Greg Rozier (Associate Producer) Casey Pettitt (Associate Producer)

Star Trek: First Contact: The Making of the Classic Film. Star Trek is one of the longest running franchises and yet the amount of reference books, art books and making-of books that come out is sorely lacking compared to something like Star Wars. In this episode of Literary Treks hosts Matthew Rushing and Casey Pettitt talk about Star Trek: First Contact: The Making of the Classic Film. We discuss the presentation, after Generations, story points, new Enterprise, new Borg, finding a director, or ratings and final thoughts. In the news section we talk about the end of the Stargazer comic mini series as well as the Ferengi one-shot. News Stargazer #3 (00:04:36) Star Trek: Ferengi (00:15:39) Feature: Star Trek: First Contact: The Making of the Classic Film Presentation (00:20:54) After Generations (00:25:56) Story Points (00:31:11) New Enterprise (00:37:12) New Borg (00:41:58) Finding a Director (00:45:46) Ratings (00:50:30) Final Thoughts (00:53:12) Hosts Matthew Rushing and Casey Pettitt Production Matthew Rushing (Editor and Producer) C Bryan Jones (Executive Producer) Greg Rozier (Associate Producer) Casey Pettitt (Associate Producer)

STORY POINTS ARE TRASH! Let's explore the options this situation presents. This and more are discussed in today's episode of Your Daily Scrum with Todd Miller and Ryan Ripley. ⏩ Check out the Full Scrum Framework course with added bonus materials, guides, murals, resources, and LIVE INTERACTION with Ryan, Todd, and Daria: https://community.agileforhumans.com/share/z2K_YMahKAiXn9T9?utm_source=manual

128. My wife, Natascha, is a faster trail runner than I am. Find out why estimating trail runs in units of time leads to misaligned expectations about how long it'll take for us to run the same trail together. You'll also learn:What story points areThree factors affecting the size of a requirementHow to account for Hick's Law and Weber's Law  when choosing an estimation scaleThe two estimation scales commonly used by agile teamsThe estimation scale my teams useThis episode is the second of three episodes taken from my new course: Estimating Business Applications. You can join for free today and get access to the first three sections containing 17 video lessons and 3 quizzes to test your understanding.Support the show

Top 10 Rewind: Should a Scrum Team Use Story Points? Let's explore the options this situation presents. All of this and more are discussed in today's episode of Your Daily Scrum with Todd Miller and Ryan Ripley. ⏩ Check out the Full Scrum Framework course with added bonus materials, guides, murals, resources, and LIVE INTERACTION with Ryan, Todd, and Daria: https://community.agileforhumans.com/share/z2K_YMahKAiXn9T9?utm_source=manual

Brian and Mike talk about why and how to use Story Points in estimating. Overview To estimate or not to estimate. There are many different views on the matter. It’s important then to start with why. Why would we spend time estimating in the first place? What is the benefit of that effort? Do all Agile teams need to estimate? Join Brian Milner and Mike Cohn as they discuss estimating using Story Points in order to plan for things such as releases. Listen now to discover: 1:51 - Mike talks about the 3 reasons why would we estimate in the first place? 4:30 - Brian asks about the #NoEstimates movement 8:00 - Brian talks about the marketing aspect of his conference talk this year 9:42 - Mike defines what a Story Point is 14:30 - Mike talks about using Story Points as a performance metric 21:20 - Mike talks about consistency in point scales across teams 25:58 - Mike talks about working with contractual constraints when using Story Points Listen next time when we’ll be discussing… Join us as we dive into Kanban with Kert Peterson. We’ll talk about this close relative to Scrum and discuss how these two can coexists in today’s Agile world. References and resources mentioned in the show Agile Estimating and Planning by Mike Cohn Agile Estimating and Planning online ecourse by Mike Cohn Woody Zuill of the #noestimates movement (and Mob Programming) Want to get involved? This show is designed for you, and we’d love your input. ● Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. ● Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He’s passionate about making a difference in people’s day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Mike Cohn is co-founder of the Scrum Alliance, and founder of Mountain Goat Software. He’s a veteran of applying Scrum and agile principles and practices to help organizations build better products, and ship them on time. Show edited by Rhett Gill

Brian and Mike talk about why and how to use Story Points in estimating. Overview To estimate or not to estimate. There are many different views on the matter. It’s important then to start with why. Why would we spend time estimating in the first place? What is the benefit of that effort? Do all Agile teams need to estimate? Join Brian Milner and Mike Cohn as they discuss estimating using Story Points in order to plan for things such as releases. Listen now to discover: 1:51 - Mike talks about the 3 reasons why would we estimate in the first place? 4:30 - Brian asks about the #NoEstimates movement 8:00 - Brian talks about the marketing aspect of his conference talk this year 9:42 - Mike defines what a Story Point is 14:30 - Mike talks about using Story Points as a performance metric 21:20 - Mike talks about consistency in point scales across teams 25:58 - Mike talks about working with contractual constraints when using Story Points Listen next time when we’ll be discussing… Join us as we dive into Kanban with Kert Peterson. We’ll talk about this close relative to Scrum and discuss how these two can coexists in today’s Agile world. References and resources mentioned in the show Agile Estimating and Planning by Mike Cohn Agile Estimating and Planning online ecourse by Mike Cohn Woody Zuill of the #noestimates movement (and Mob Programming) Want to get involved? This show is designed for you, and we’d love your input. ● Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. ● Got an agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He’s passionate about making a difference in people’s day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Mike Cohn is co-founder of the Scrum Alliance, and founder of Mountain Goat Software. He’s a veteran of applying Scrum and agile principles and practices to help organizations build better products, and ship them on time. Show edited by Rhett Gill

Daniel Vacanti on Agile World has a great conversation with Sabrina C E Bruce and Karl A L Smith on everything from closing the loop on customer journeys to drunk agile planning and drunk agile. With more information Actionable Agile Analytics and that Story Points are evil lots of can's have have been opened in this show. Daniel Vacanti on LinkedIn https://www.linkedin.com/in/danielvacanti/ Kanban: Prokanban.org Actionable Agile Metrics for Predictability book: Actionable Agile Metrics for Predictability Lean Pub show: When Will It Be Done? Co Hosts Sabrina C E Bruce Karl A L Smith #Agile_World #AgileWorld #Agile #AgileTalkShow #AgileManifiesto #AgileCoach #ScrumMaster English Agile World English Website Agile World English LinkedIn AgileWorld.English Facebook Agile World © 2021 Agile World Broadcast Network, Hollywood, California | English content Co-hosts --- Send in a voice message: https://anchor.fm/agile-world/message

In Scrum: The Art of Doing Twice the Work in Half the Time by Sutherland, Guru found an inspiring book that explains how, and where Scrum can be used, from visual boards for painting a house, to Scrum in education. The book makes Scrum easy to understand, and helps change agents learn how to present the framework to stakeholders and teams. How can Angela (the Agile Coach) quickly build healthy relationships with the teams she's supposed to help? What were the steps she followed to help the Breeze App team fight off the competition? Find out how Angela helped Naomi and the team go from “behind” to being ahead of Intuition Bank, by focusing on the people! Download the first 4 chapters of the BOOK for FREE while it is in Beta! About Gurucharan Padki Gurucharan Padki comes with 18 years of experience in the IT industry, of which he has spent more than a decade in the Agile world delivering products, programs and projects with focus on engineering and quality . He has played the role of product owner, scrum master and agile coach in multiple organizations across India and the world driving transformations. You can link with Gurucharan Padki on LinkedIn.

We are LIVE. On the 10th episode, we close out the second sprint of episodes with a banger VIDEO. We recap the last 4 episodes. Tech Culture, APIs, Frontend/UI/UX, Backend and Infrastructure. We discuss the last tech news... Twitter APIs in the Johnny Depp Amber Heard case, Big Tech Companies doing layoffs, Tech Company offers and what it really means to make 500k in a tech company. EMAIL US AT: storypointsdev@gmail.com FOLLOW US ON INSTAGRAM: story_points --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app

The age old question.. Which technique is best for estimation and forecasting? Join V. Lee Henson, President & Founder of AgileDad as we get this all hammered out and give you the answer you seek once and for all.

Joe Schurman teaches from his deep experience in the software, machine learning, AI, and processes that organizations need today as they transition to data-driven technology companies. He names some of the cloud services and tech tools he uses to lead clients to start with a user case, break it into stories,  build a team led by the solution owner, assign the stories to developers to build, and iterate product demos until the Minimum Loved Project (MLP) is achieved. Joe offers observations on investing the “right” amount of time in projects, and wisdom on developing a learner mindset.   Key Takeaways [2:06] Joe Schurman is a 2nd-degree black belt in Kung Fu. He once judged a competition in Las Vegas. He has four children; two daughters and two sons. [2:57] Joe is an expert on the fringes of what we can do with computing technology. What we can do changes every day. In the past couple of years, from an AI perspective, with data and automation, it's taken leaps and bounds. [4:30] We're still pretty far away from general AI, despite Sophia, an AI robot that was granted Saudi Arabian citizenship in 2017. Today's AI depends on the programming we give a machine and its interpretation and output. Joe's focus is narrow or weak AI. His business colleagues call it magic. Computer vision is an area he loves. [5:45] Joe uses a lab environment across Google Cloud Platform, Microsoft Azure, and Amazon Web Services. The capabilities that have come up in the last year are “just insane” with what you can do with computer vision and building libraries of what the machine can see. [6:06] Joe loved seeing a computer vision capability demonstration at AWS re:Invent of tracking every NFL player on the field and predicting injuries and other types of output and insights in real-time. The machine used narrow AI to access a library seeded with “a ton” of data to interpret the action. [7:15] What you can do with this technology comes down to the data that you feed the engine. Think about the amounts of data that organizations have to sift through to generate reflective or predictive insights. Auto machine learning helps organize the data into useful information such as anomaly detection in software engineering. The data can also come from tools like GitHub and Jira. [8:25] Joe did a fun computer vision project on UAPs for the History Channel, working with some of the nation's top military leaders, building a library of video and audio data to be able to detect unidentified aerial phenomena that were not supposed to be entering our airspace, and curating that library. [10:06] AI started with the idea of speeding up processes, such as getting an app to market faster or gathering insights quicker to make business decisions more timely. [11:28] AI can enhance human performance. Joe starts by finding people who know how to fail fast; to get a Minimum Viable Product (MVP) out the door. Solutions such as quality engineering automation, test automation, and monitoring services for DevOps detect bugs and performance issues quickly and ensure that the quality of the team is sound.[12:47] Joe notes the importance of individuals performing, contributing to, and collaborating as a team. Set your organization and standards governance up first. Look for a platform of technology to leverage that enables you to build and tinker. Finding the latest and greatest tool is no good unless it provides the right level of collaboration with their platform and connection to different processes. [14:53] When introducing ML to an organization, start with discovery, to understand the culture and talent within the organization. How are they communicating today? Joe sees the biggest gap between data scientists and data engineers. Projects tend to fail without collaboration, regardless of the tech. If the data scientists don't understand the domain, then the platform is irrelevant,[17:28] Joe stresses the need for a methodology in place to make any of these aspirations work for your organization. After discovery, there's an align phase. Focus on the outcome and the use case. The solution owner is crucial. The solution owner leads the technology team and brings them together around the client's outcome to develop that use case.[18:12] If you can't take an actual use case and break it down into bite-sized chunks or user stories, then the project will never be on the right track. Start with the use case to mitigate risks. Break the use case into user stories. Match the user stories with the number of engineers that can develop a number of user stories within a given time frame. [18:38] Those user stories given to the engineers are deducted into Story Points, in the Agile Process of engineering software. Price Waterhouse Coopers (PcW) has taken it to the next level, being able to do Engineering as a Service, being able to do it at scale, and being able to pivot quickly.[18:58] Joe explains what can happen if you have a great idea, take three to six months to break down the use case, and fill all the requirements, but hand it off to the Dev team that has no idea what the use case is: you get irrelevant software that doesn't tie back to the outcome! [19:22] Keep the solution team engaged in building the bridge between the subject matter expert stakeholders and the engineers. Every two weeks, demonstrate the iteration or program increment you have built. Does it match the outcome? Does it provide any relevance? Then take the feedback and figure out what happened in that iteration. Fix errors. You will build a product that has value to launch. [20:45] Communicate a lot, so all the people are on the same page! When you have stovepiped organizations where the departments don't talk to one another, you waste time, effort, and money building a product no one will use. One of Joe's colleagues, José Reyes, uses the term Minimum Lovable Project (MLP), where people rally around the outcome, not just the tech. [22:33] What skills and knowledge will the leaders of PwC need to endure for the next five years? Joe says first are character and attitude; people that have a hunger to build something, with a fail-fast mentality, and that are excited to learn constantly, that read every day and learn new technology. [24:27] Then know the tools. Documents exist on the internet for every solution and there is access to services like GitHub to download projects and starter templates without being an expert but just reading the README file and installing the base-level template, learning as you go, and as you tinker. That's way more valuable than coming in as a book-smart expert in a specific product or technology. [24:57] When it comes to tooling, there are products like the Atlassian platform with Confluence and Jira. For an AI stack, Joe typically works with AWS, GPC, and Microsoft, more so on the Amazon side with AWS AI tools, like Rekognition, Glue DataBrew, Redshift ML, Comprehend, and more. Amazon, Microsoft, and Google produce so much documentation and certification to get you up to speed. [26:30] Judgment, wisdom, and character will not be replaced by AI anytime soon. There's still room for philosophy in leadership. There are tools and technologies to speed up the processes, but not the individuals. There are no general AI solutions out yet to replace a pod of application developers, designers, and solution owners to execute a successful MVP or MLP out the door for a client. [27:55] Advice to CEOs: Be patient and understanding. Be willing to fail fast. Support tinkering and R&D, even if the project doesn't work out. Organizations are generally realizing that today they need to be data-driven, technology companies but there is still hesitance over the risk that needs to be taken. [30:03] Why would an insurance company or other traditional company need R&D? Look at Loonshots, by Safi Bahcall for some ideas about R&D. [30:56] Joe shares how he got to this point in his career. He wanted to play baseball but started at Compaq (now HP) when he was 18, writing scripts in Unix and other environments. Just being able to make certain changes to help clients get products faster and seeing the quick response from the outcomes felt like a home run to him! [31:49] Years later, Joe went on his own, with a vision to create telehealth before telemedicine was a thing, using Skype for Business and Microsoft Lync, enabling an API for that. Seeing people connect through a technology he had built, replaced the need to be a baseball star! Joe is grateful for the break he got at a young age and enjoys his work. [33:22] When Joe first started, he was trying to be the smartest person in the room, seeing the instant gratification of making code snippets that tested successfully. Eventually just building the app wasn't enough for him. He got the dopamine hit from seeing users interacting with his code and seeing its value. [34:58] Joe's mentors include many people he worked with. X. D. Wang at Microsoft Research inspired him to tinker, build, and focus on the short-run more than the long-run. Randeep Sing Pal at Microsoft Unified Communications was another great mentor. Also Steve Justice and Chris Mellon, in terms of character and collaboration. Joe shares how they mentored him. [37:23] Jan says something we forget about technology is that there are a lot of failures and attempts before the success hits. We have to be mindful of that as leaders to give people time and space to do really creative, cool things. [38:01] Joe appreciates the opportunity to discuss these things. Joe spent a lot of his career building software solutions that were way ahead of their time. It's frustrating to see telemedicine so successful now, but not when he attempted it. He had to learn to let go. It's not just about releasing bleeding-edge tech; you've got to find some value associated with it to resonate with the end-user. [39:31] Always think about the outcome and understand your audience first. And then be able to supplement the back end of that with bleeding-edge technology, development, tinkering, failing fast, and all the things that go with software engineering. Also, be humble! Get perspective from outside your bubble to build a better solution and be a better person. [40:49] WHenever you're setting out to build anything, start with a press release! Write a story of what it would look like if it were released today. Then just work back from there!   Quotable Quotes “There are so many new and cool technologies and innovations that are coming out at the speed of thought, which are pretty fascinating.” “I've been in real cloud engineering for about a decade, and from an AI perspective, with data and automation, over the past five to 10 years, in terms of running on a cloud environment, and it's just taken leaps and bounds.” “You've got to be able to connect that [data] environment to a use case or an outcome. If you can't do that and you can't enable a data scientist to understand the domain, then the data platform is irrelevant. I see a lot of performance issues occur because of that disconnect.” “If you can't take an actual use case and break it down into bite-sized chunks or user stories, then the project will never be on the right track.” “In this industry, you're constantly learning; constantly reading. I'm reading every day and learning about new technology every day and how to apply it and how to tinker with it. I need people on the team … that have that ability or that hunger to tinker and learn.” “Transitioning from a ‘knower' mindset to a ‘learner' mindset was the biggest shift for me.” “Always think about the outcome and understand your audience first. And then be able to supplement the back end of that with bleeding-edge technology, development, tinkering, failing fast, and all the things that go with software engineering.”   Resources Mentioned Joe Schurman, PwC Joe Schurman on LinkedIn PwC Sophia robot granted citizenship I, Robot film Weak AI Google Cloud Platform Microsoft Azure Amazon Web Services AWS re:Invent GitHub Atlassian Jira Unidentified, The History Channel José Reyes, PwC The Shackleton Journey Atlassian Confluence AWS Rekognition AWS Glue DataBrew AWS Redshift ML AWS Comprehend Steve Justice on LinkedIn Chris Mellon Loonshots: How to Nurture the Crazy Ideas That Win Wars, Cure Diseases, and Transform Industries, by Safi Bahcall  

Show notes:* Episode #7: топ-задача тижня* Аналітика Джина: 50 тис відгуків на тиждень This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit newsletter.maxua.com

A recent article by Gabor Csomak discusses how doing fewer story points will over time increase your velocity. The concepts presented are on point, but a clear discussion needs to be had regarding the use of the words Capacity and Velocity as they are not interchangeable. https://medium.com/nerd-for-tech/why-committing-to-less-story-points-will-increase-your-velocity-d821380c6c5

Episode Sponsored by Glass Art Society and Fluxeon Shownotes on www.taminglightning.net Hello lightning Tamers this is episode number 46. And in today's podcast, I'll be joined by Ben Orozco. Ben has co-hosted on the podcast in theTaming Lighting x GEEX collaboration, a 4 part series called Intro to Plasma.Today Ben will be formally introduced as guest on Taming Lightning and we well be talking  Neon as Systems building, the use of light to depict space, and neon as a design language. Music credits  Preview - Retro by ONE  The opening theme -Taming Lightning by Trav B. Ryan    Sponsor - Good2Go by ONE Credits - Walking by Ras-Hop I found the subject of Systems Building to be as an important tool for artists and neon bender to be just as applicable beyond the focus of the this podcast. I do find it valuable to check out  the episode on Story Points from the podcast Two Scrums up, which helps you to quantify an estimate of the effort and time required to complete a task or piece of work. So be sure to check out the show notes on Taming lightning.net for podcast, books, and resources mentioned in this episode.

The story of Ruth is ultimately a story about the commitment God makes to accomplishing His plans. In this episode, Dot and Cara talk about the book of Ruth and the way it points to Jesus as the kinsman redeemer who allows us to claim our inheritance from God. They also reflect on the meaning of Good Friday, which reminds us to have faith even when we're grieving and don't understand why life has turned out a certain way. Episode RecapStart by writing down Ruth 4:13-14 (0:13)It's easy to become bitter when life doesn't turn out how you expected (1:58)Ruth is really a story about Jesus becoming our kinsman redeemer (5:33)God accomplished His plan even in the midst of terrible circumstances (11:10)Good Friday reminds us that the darkest times can lead to a miracle (22:19)We can take the next step in faith that God is working (24:55) Send us an email to let us know what you're learning - hello@dotbowen.com Find Dot Bowen on Instagram and Facebook

In this episode, Brian Orlando and Om Patel discuss the dreaded topic of estimation in agile software development. We discuss the pros and cons of each type of estimation, starting with time/hours-based estimates, then moving to story points and finally flow (or #noestimates). 0:00 Intro0:18 Topic Intro1:28 Why Estimate?3:15 Real Deadlines... Sometimes...5:13 Why Estimate? A Product Viewpoint7:49 Estimation or Guess10:59 Guesses, Demands, & Tricks13:36 "Pick a Date" Behavior15:44 Methods of Estimation: Hours (or Time)22:44 If You Have to Estimate in Hours...24:24 Other Games with Time Estimates27:59 The Evils of Individual Time Metrics32:26 Relative Estimation: Story Points36:23 Forgetting About Risk & Complexity41:19 Doing Story Points Right42:58 Flow-Based Estimation (aka. #NoEstimates)46:39 Breaking Stories - the Secret to Success in Flow50:23 Flow in Kanban53:52 Delivery of Business Value59:45 Future Business Value Podcast1:02:40 Wrap-Up1:02:53 Blooper Reel= = = = = = = = = = = =Available on YouTube:https://youtu.be/Hugv72aFYcIPlease Subscribe to our YouTube Channel:https://www.youtube.com/channel/UC8XUSoJPxGPI8EtuUAHOb6g?sub_confirmation=1= = = = = = = = = = = = Apple Podcasts:https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596Google Podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5idXp6c3Byb3V0LmNvbS8xNzgxMzE5LnJzcwSpotify:https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3Amazon Music:https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-PodcastStitcher:https://www.stitcher.com/show/agile-podcast-2= = = = = = = = = = = =AP50 - Estimation (Hours vs. Story Points vs. Flow)

For this very first episode of the Story Points podcast, we (Roger King, Joseph Micceri, and George Markantonis) are a light hearted group of software engineers talking about different stories in our careers. We start with talking about how we are navigating working from home long term, how we got started in this booming field of software engineering,  and discuss the many ways people can break into the industry.Buzzwords: Story Points, Retros, Sprints, Full-Stack, DevOps, Java, Tickets

Scrum Teams Should Stop Using Story Points! Let's explore the options this situation presents. All of this and more are discussed in today's episode of Your Daily Scrum with Todd Miller and Ryan Ripley. What do you think? Let us know in the comments! Take a Professional  Scrum with Kanban Course with Todd, Ryan, and Daniel Vacanti! https://www.eventbrite.com/e/professional-scrum-with-kanban-psk-online-certification-class-psk-i-tickets-167900832911 Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems -  https://amzn.to/3fMpH5a Join Ryan and Todd in a Professional Scrum Master course:  https://www.scrum.org/agile-humans And make sure you subscribe to the channel! DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. There is no additional charge for you! Thank you for supporting the channel so we can continue to provide you with free content each week! FTC DISCLAIMER: This video is not sponsored by anyone. Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems. #scrum #agile #scrummaster See omnystudio.com/listener for privacy information.

Using Business Value Points (BVP) for User Stories to help define scope, help prioritize and make planning smoother. BVP can use the same framework as Story Points (i.e. a modified Fibonacci Sequence). For example: BVP 13 - Will provide a definite and significant tangible ROI (increase revenue, transactions, generate repeat customers) or is a Compliance Item which will result in Penalties if not done (Loss of Revenue) BVP 8 -  Will provide some ROI (either a small - medium or is purely speculative) BVP 5 - Is Necessary Cost of Doing Business but no Significant ROI BVP 3 - Definitely will Delight the Customer but Low ROI BVP 1  - Nice to Have; May Delight the Customer but Little to No ROI  

Agile World with our hosts Sabrina C E Bruce and Karl Smith talk with Mark Walsh and Cyril Costa and a host of thousands well a few who could make it about Story Points on the meetup session Story Points are DEAD Tuesday, July 6. Agile World magazine show with Sabrina C E Bruce and Karl Smith on YouTube. #Agile_World #AgileWorld #Agile #AgileTalkShow #AgileManifiesto #AgileCoach #ScrumMaster Online Website https://agile-world.news/ LinkedIn https://www.linkedin.com/company/agile-world-news/ Facebook https://www.facebook.com/agileworldnews Instagram https://www.instagram.com/agileworldnews/ Twitter https://twitter.com/AgileWorldNews Tumblr https://www.tumblr.com/blog/view/agile-world YouTube https://www.youtube.com/c/AgileWorld Medium Agile World News https://medium.com/agile-world-news Podcast Spotify https://open.spotify.com/show/1aMY1R5ct7EqrehR4aZUat Apple Podcasts https://podcasts.apple.com/gb/podcast/agile-world/id1553727032 Google Podcasts https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy80Y2FmNDhmYy9wb2RjYXN0L3Jzcw== Pocket Casts https://pca.st/vbyfqprr Anchor https://anchor.fm/agile-world Breaker https://www.breaker.audio/agile-world Radio Public https://radiopublic.com/agile-world-WPNL9j Co Hosts Sabrina C E Bruce https://www.linkedin.com/in/sabrinabruce/ Karl A L Smith https://www.linkedin.com/in/karlsmith2/ Agile World © 2021 Broadcast Media, Hollywood, California | English content by Karl A L Smith and Sabrina C E Bruce --- Send in a voice message: https://anchor.fm/agile-world/message

Agile World with our hosts Sabrina C E Bruce and Karl Smith talk with Mark Walsh about Story Points. Insightful as always Mark describes the problem leaving our host aghast with the knowledge of Business Agility people. Asking teams to do "more points than last sprint" as if points really deliver features and value. Not to be missed if your involved in any kind of Agile and have any intention of seeing the benefits of Agile realised. Mark also explains how you can in fact see real value delivered regardless of your toolset, worth a listen for that gem alone. If you want to join in the discussion come to the meetup session Story Points are DEAD Tuesday, July 6, 2021 6:00 PM to 8:00 PM GMT+1 Agile World magazine show with Sabrina C E Bruce and Karl Smith on YouTube. #Agile_World #AgileWorld #Agile #AgileTalkShow #AgileManifiesto #AgileCoach #ScrumMaster #Agile20ReflectFestival #Agile20ReflectEvent #Agile20Reflect Online Website https://agile-world.news/ LinkedIn https://www.linkedin.com/company/agile-world-news/ Facebook https://www.facebook.com/agileworldnews Instagram https://www.instagram.com/agileworldnews/ Twitter https://twitter.com/AgileWorldNews Tumblr https://www.tumblr.com/blog/view/agile-world YouTube https://www.youtube.com/c/AgileWorld Medium Agile World News https://medium.com/agile-world-news Podcast Spotify https://open.spotify.com/show/1aMY1R5ct7EqrehR4aZUat Apple Podcasts https://podcasts.apple.com/gb/podcast/agile-world/id1553727032 Google Podcasts https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy80Y2FmNDhmYy9wb2RjYXN0L3Jzcw== Pocket Casts https://pca.st/vbyfqprr Anchor https://anchor.fm/agile-world Breaker https://www.breaker.audio/agile-world Radio Public https://radiopublic.com/agile-world-WPNL9j Co Hosts Sabrina C E Bruce https://www.linkedin.com/in/sabrinabruce/ Karl A L Smith https://www.linkedin.com/in/karlsmith2/ Agile World © 2021 Broadcast Media, Hollywood, California | English content by Karl A L Smith and Sabrina C E Bruce --- Send in a voice message: https://anchor.fm/agile-world/message

Today's question is from a viewer who wants to know whether or not a Scrum Team use Story Points? It really depends on your context and situation. Story Points can certainly be a better option than hours. Ryan and Todd also provide options to Story Points and other considerations that they take into account when deciding between story points and other options for estimation. Want to learn more about Scrum? Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems - https://amzn.to/3fMpH5a Join Ryan and Todd in a Professional Scrum Master course: https://www.scrum.org/agile-humans And make sure you subscribe to the channel! DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. There is no additional charge for you! Thank you for supporting the channel so we can continue to provide you with free content each week! FTC DISCLAIMER: This video is not sponsored by anyone. Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems. #scrum #agile #professional scrumSee omnystudio.com/listener for privacy information.