When it comes to agile project delivery, progress is normally measured in the form of story points, or hours burned for a given sprint.\u00a0From the business owners down, leadership is always giving the mantra, "When will it be done?" and \u201cWhere are we now?\u201d\u00a0Typically, leadership wants that consistency and confidence in knowing what to expect and when in order to build trust in delivery.\nNotice that consistency is the key word here.\u00a0However, the reality is that balancing the workload in a consistent manner in a single team, let alone across multiple teams, is challenging. When using story points, since they are relative, two different same-sized teams could be producing the same amount of total work, but team A could show 30 story points a sprint and team B 150 story points a sprint.\u00a0This naturally drives up leadership frustration and decreases trust!\nNow that doesn't necessarily mean team B is delivering five times more results or working five times as hard. Since story points are relatively sized, it more likely means that team B's baseline is five times bigger than team A's. However, there is a core challenge with having that level of variance between team performance when it comes to working across multiple teams in a scaled delivery model or having a standard delivery practice across multiple projects for budgeting and shared delivery purposes.\nOne solution to this challenge is to normalize your delivery team pointing scale.\u00a0 Details of this can be found at the Scaled Agile Framework site under the subheading "Normalizing Story Point Estimation."\nBut the normalization process doesn't stop at the setup.\u00a0There are further actions needed to ensure and keep story points normalized so they don\u2019t go too far into the \u201cdeep end\u201d with variability.\nFirst, look at comparing baselines.\u00a0Traditionally, teams will take the smallest story and baseline that.\u00a0 Here are a few more suggestions on ensuring a consistent baseline:\n1. Don't baseline just the smallest story.\u00a0Instead follow Mike Cohn's suggestion of baselining two stories, called "triangulation." My suggestion is to do three stories. That way there is more consistency in the baseline\n2. Make sure you have a person from an external team cross-check the baseline for agreement.\u00a0If that person sees a large delta in the baseline, then that should be adjusted to the "normalized baseline" immediately\n\u00a0The next part is to manage your delivery closely for any variances and work on eliminating them. Here are some example cases:\n1. Velocity inflation: The team slowly "shifts" its baseline up so that over time a \u201c2\u201d story is now a \u201c3\u201d story and so on.\u00a0This inflation happens when a team\u2019s success is measured purely by velocity.\u00a0This should also be periodically cross-checked by external team members and business value should be focused more than story points, since velocity inflation provides only the appearance of more value but is a "false positive."\n2. Poor requirements: Consider the backlog the \u201cjet fuel\u201d for flying to any product destination.\u00a0If the fuel isn't refined enough, the jet will sputter, slow down and possibly crash.\u00a0To ensure the highest quality fuel, set standards for story quality when entering a sprint and review during sprint planning.\u00a0This doesn\u2019t need to go overboard, but \u201cjust enough\u201d to get the team to commit and do the work without further delay or creating the wrong result.\n3. Not enough quality: The whole agile delivery process is like a machine.\u00a0If one part fails, the whole machine will fail.\u00a0If velocity begins to slow over time, look at the amount of QA resources and measure the bug counts and severities.\u00a0Make sure the code quality is high by employing proper programming quality practices.\u00a0Many sources exist, including the books Pragmatic Programmer by Andy Hunt and Dave Thomas, Clean Code by Robert \u201cUncle Bob\u201d Martin and Extreme Programming Explained by Kent Beck.\nThere are many points of failure and few points of success when it comes to normalizing your story pointing for delivery. In some mature organizations, estimation isn\u2019t even practiced anymore, since interpreted as a productivity loss and work is measured strictly by the value of the software produced.\u00a0 However, this requires a high degree of consistency, experience, confidence and trust to reach.\u00a0For most organizations and consulting companies, delivering with a high level of consistency is a holy grail.